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ABSTRACT 


Planning  and  controlling  the  software  development  process 
has  shown,  in  the  past,  to  be  an  extremely  diffcult  task. 

The  estimation  of  resource  requirements,  development  costs, 
risk  profiles  and  project  feasibility  has  often  proven  to  be 
inaccurate,  thus  costing  the  government  time  and  dollars. 
However,  by  using  obtainable  management  parameters,  and  simple 
engineering  and  operations  research  techniques,  estimating 
can  be  done  easily  and  accurately  by  taking  a  macro  approach 
to  the  estimation  problem. 

This  study  will  present  the  background  and  mathematical 
basis  for  a  software  cost  estimation  model.  In  addition,  an 
example  of  an  automated  application  of  the  model  will  be  pre¬ 
sented  and  discussed. 
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INTRODUCTION 


A •  GENERAL 

Software  development  within  the  Federal  Government  has 
been  significantly  marred  by  a  history  of  projects  that  are 
characterised  by  cost  and  schedule  overruns,  and  a  delivered 
end-product  that  fails  to  provide  the  desired  performance 
and  function  originally  required.  This  statement  is  not 
mere  conjecture,  but  has  been  observed  and  documented  in  the 
past.  The  compilation  of  responses  to  a  questionnaire  sent 
out  by  the  United  States  General  Accounting  Office  (GAO)  to 
one  hundred  and  sixty  three  software  contracting  firms  and 
one  hundred  and  thirteen  experienced  federal  project 
officers  has  ascertained  that  in  over  50  percent  of  the  cases, 
52.0  percent  of  the  respondents  experienced  software  develop¬ 
ment  calender  overruns,  50.4  percent  of  the  respondents 
experienced  software  cost  overruns,  and  43.3  percent  of  the 
respondents  received  software  that  required  substantial  in- 
house  correction  or  modification  prior  to  being  effectively 
used.  [Ref.  26:  3-10] 

In  an  industry  in  which  the  Federal  Government  incurs 
expenditures  and  fiscal  obligations  well  into  the  billions 
of  dollars,  the  process  of  resource  estimation  and  project 
control  for  software  development  is  a  major  budgetary  concern. 
As  development  costs  steadily  and  rapidly  escalate,  this 
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concern  gains  added  complexity  (Figure  1)  and  some  manner  of 
formal  methodology  which  allows  the  project  manager  to 
estimate  the  resource  requirements  and  to  control  the  project 
becomes  necessary. 

The  requirements  of  such  a  methodology  must  allow  for 
the  capability  to  operate  with  any  size  project  yet  still 
remain  a  function  of  manageable  parameters  such  as  effort 
and  development  time.  These  parameters  require  relationships 
to  the  system  size  (delivered  source  lines  of  code)  in  terms 
of  such  environmental  factors  as: 
system  complexity 

use  of  and  type  of  software  engineering  tools 

user  interface 

use  of  a  target  machine 

use  of  a  development  computer 

the  development  language  used 

other  human  factors 

[Ref.  20:  14] 

In  addition,  the  concept  of  system  difficulty  is  a  factor 
that  must  be  taken  into  account,  not  only  in  terms  of  the 
number  and  types  of  source  lines  of  code,  but  also  in  terms 
of  the  development  approach  and  the  integration  of  modules 
and  subprograms. 

The  Department  of  Defense  (DOD)  has  taken  steps  to 
formalize  and  standardize  the  governing  of  the  life-cycle  of 
automated  information  systems  (AIS).  Life  cycle  management 
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Percent  of  Cost 


ill 


Figure  1 


Hardware  versus  Software  Cost  Trends 
[Ref.  3:  1227] 


(LCM),  as  defined  by  the  Department  of  Defense,  is  "the 
process  for  administering  an  AI3  over  its  whole  life  with 
emphasis  on  strengthening  early  decisions  which  shape  AIS 
costs  and  utility."  [Ref.  6:  2] 

Among  the  objectives  of  life  cycle  management  is  to 
assure  the  lowest  total  overall  cost  and  to  provide  visibility 
for  resource  requirements.  In  order  that  a  project  manager 
might  plan  and  control  a  software  development  project  through¬ 
out  the  entire  life-cycle,  he  must  be  able  to  answer  four 
simple  management  questions  in  terms  of  cost  and  resources: 

Is  the  project  feasible? 

What  are  the  resource  requirements? 

How  long  will  it  take? 

What  are  the  risks? 

Unfortunately,  the  past  has  shown  that  these  simple  questions 
can  prove  to  be  extremely  difficult  to  answer.  Wot  only  must 
these  questions  be  answered  during  the  initial  stage  of  the 
project,  but  also  throughout  the  entire  life  of  the  project. 
"Software  development  is  dynamic ...  not  static."  [Ref.  20:  131] 

3.  SCOPE 

This  study  is  directed  toward  the  role  of  the  manager, 
his  ability  to  address  and  answer  the  four  management  ques¬ 
tions,  and  the  role  of  these  questions  in  life-cycle  control. 
Much  of  the  background  information  is  technical/mathematical 
in  nature.  These  topics  will  be  presented  in  such  a  manner 


14 


as  to  allow  the  reader  to  grasp  the  fundamental  concepts 
without  unnecessary  inundation  by  the  mathematics  involved. 

The  emphasis  will  remain  on  the  conceptual  aspects  and  in 
the  resultant  numerical  answers. 

The  principles  presented  in  this  study  are  applicable 
to  software  development  project  managers  both  inside  and 
outside  the  federal  government.  Because  the  Department  of 
Defense  is  one  of  the  largest  single  users  of  computer 
technology,  this  study  will  reflect  Department  of  Defense 
policies  and  techniques. 

C.  ASSUMPTIONS 

It  is  assumed  that  the  reader  has  a  working  understanding 
of  life  cycle  management  and  the  software  development  process. 

D.  ORGANIZATION  OF  STUDY 

This  study  will  be  organized  in  such  a  manner  as  to  flow 
from  the  conceptual  to  the  specific.  After  the  presentation 
of  necessary  background  material  in  Chapter  II,  greater  speci¬ 
fication  occurs  in  Chapter  III  in  dealing  with  the  Rayleigh 
curve,  its  characteristics,  and  its  relationship  to  the  life- 
cycle.  Chapter  IV  will  deal  with  the  characteristics  and 
application  of  the  Putnam  Software  Equation.  Chapter  V  will 
present  computerized  applications  of  this  methodology  using 
the  SLIM  (Software  Life  Cycle  Model)  software  estimation  pack¬ 
age.  This  study  relies  heavily  on  the  writings  and  observa¬ 
tions  of  Lawrence  H.  Putnam,  President  of  Quantitative 
Software  Management,  Inc. 
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E .  SUMMARY 


This  study  will  present  a  means  of  answering  the  four 
basic  management  questions  concerned  with  the  control  and 
planning  of  software  development: 

Is  the  project  feasible? 

What  are  the  resource  requirements? 

How  long  will  it  take? 

What  are  the  risks? 

This  will  be  accomplished  in  a  manner  which  uses  the  basic 
management  parameters  of  time,  cost,  and  manpower,  as  the 
inputs  for  planning  and  control. 
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II.  BACKGROUND 


A.  AN  OVERVIEW  OF  LIFE-CYCLE  MANAGEMENT  AND  THE 
SOFTWARE  DEVELOPMENT  PROCESS 

1 .  Life-Cycle  Management 

The  Department  of  Defense  subdivides  the  life-cycle 
of  an  automated  information  system  into  five  broad  phases: 
Mission  Analysis/Project  Initiation 
Concept  /Development 
Definition/ Design 
System  Development 
Deployment /Operation 
[Refs.  6:  2,  10:  para  1003.3] 

These  phases  are  sequential  and  act  as  a  control  mechanism 
for  both  systems  development  and  management  accountability, 
a.  Mission  Analysis/Project  Initiation 

This  phase  serves  to  identify  a  mission  element 
need  in  terms  of  functional  requirements,  validate  the  need, 
and  recommend  the  exploration  of  alternate  functional  con¬ 
cepts  that  satisfy  the  need.  Although  this  particular 
structure  exists  in  large  projects  requiring  extensive 
resource  commitments,  the  philosophy  of  mission  need  can  be 
persuasive  in  smaller  programs  and  should  be  carried  out  and 
documented  in  a  like  manner.  This  phase  is  completed  at 
Milestone  0,  the  approval  of  the  Mission  Element  Need 
Statement  (MENS). 
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b.  Concept  Development 

The  Concept  Development  phase  serves  to  define 
requirements,  evaluate  the  alternative  methods  that  satisfy 
the  need,  and  to  recommend  one  or  more  feasible  concepts  for 
further  exploration.  This  phase  terminates  with  approval 
for  the  vendor  to  demonstrate  the  alternative  concepts  or  to 
proceed  directly  to  the  definition  and  design  phase,  given 
that  one  concept  has  been  selected.  Termination  of  this 
phase  indicates  Milestone  I. 

c.  Definition/Design 

The  purpose  of  the  Definition/Design  phase  is  to 
fully  define  the  functional  requirements  in  terms  of  system/ 
subsystem  specifications,  and  to  design  an  operable  system. 
This  phase  terminates  at  Milestone  II  when  both  the  defini¬ 
tion  and  design  concepts  have  been  approved. 

d.  System  Development 

The  System  Development  phase  serves  to  develop, 
integrate,  test  and  evaluate  the  system.  This  phase  is 
completed  when  the  appropriate  functional  officials  grant 
approval,  certifying  that  the  system  satisfies  the  mission 
need.  Approval  constitutes  Milestone  III. 

e.  Deployment  and  Operation 

This  phase  covers  the  implementation  of  the 
approved  system,  the  continued  operation  of  the  system,  and 
all  required  maintenance  and  modification. 
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The  Software  DevelODment  Process 


There  are  several  ways  of  viewing  the  software 
development  process.  For  purposes  of  this  study,  the  soft¬ 
ware  development  process  will  consist  of  four  phases: 

Systems  Definition 

Functional  Design/Specification 

Development 

Operarion  and  Maintenance 

The  phases  are  essentially  sequential,  but  some  degree  of 
overlap  can  be  permitted.  In  addition  to  the  four  phases, 
there  is  one  step,  Installation,  which  overlaps  both  the 
Development  phase  and  the  Operation  and  Maintenance  phase 
( Figure  2 ) . 

a.  Systems  Definition 

Systems  definition  includes  the  complete  defini¬ 
tion  of  the  preferred  alternatives  or  alternative,  the 
establishment  of  bounds  on  manpower  effort  and  development 
time,  and  the  refinement  of  costs. 

b.  Functional  Design/Specification 

This  phase  involves  the  preparation  of  detailed 
system  specifications  for  both  the  application  and  technical 
software  support,  and  the  finalization  of  technical  proce¬ 
dures  and  programming  policies.  Finally,  detailed  system 
specifications  are  converted  into  detailed  programming 
specifications . 


c.  Develooment 


The  Development  phase  can  be  further  subdivided 
into  two  steps: 

Design  and  Coding 
Test  and  Validation 

These  two  steps  include  the  coding  of  applications  specifica¬ 
tions  and  the  conducting  of  unit  and  string  testing  of  the 
machine  executable  instructions.  In  Addition,  program  docu¬ 
mentation  is  completed.  System  testing  requirements  are 
prepared  and  the  test  is  carried  out. 

d.  Operation  and  Maintenance 

The  final  phase.  Operation  and  Maintenance, 
includes  system  refinement,  tuning,  post-implementation 
reviews,  and  the  continued  operation  and  required 
maintenance . 

e.  Installation 

The  installation  of  the  system  overlaps  the  end 
of  the  Development  phase  and  the  beginning  of  the  Operation 
and  Maintenance  phase.  This  step  includes  implementation  and 
conversion  planning  as  well  as  the  actual  conversion  and 
phased  implementation.  [Ref.  2:  14-18] 

B.  MICRO  VERSUS  MACRO  METHODOLOGY 

The  traditional  approach  to  size/time/cost  estimation 
has  been  the  use  of  a  micro-methodology.  (Table  1)  This 
methodology  is  largely  intuitive  and  begins  by  fixing  the 
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Table  1 


Traditional  Methods  of  Cost  Estimation 
[Refs.  1:  229-231,  11:  24,  27:  12-13,  29:  618-619] 

1.  Experience  Method 

2.  Constraint  Method 

3.  Top-Down  Estimating 

4.  Similarities  and  Differences  Estimating 

5 .  Analogy  iMethod 

5.  Standards  Estimating 

7.  Ratio  Estimating 

8.  Bottom-Up  Estimating 

9.  Units  of  Work  Method 

10.  Smoothing  and  Extrapolation  Estimating 

11.  Number  of  Instructions 

12.  Quantitative  Method 

13 .  Cost  Per  Instruction 

14.  Percent  of  Hardware  Method 
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size,  start  date  and  duration  of  each  distinguishable 
activity.  Adjustments  are  estimated  and  applied  based  on 
the  caliber  of  personnel,  complexity,  and  so  forth.  Finally, 
activities  are  arranged  using  network  models  such  as  PERT 
(Program  Evaluation  and  Review  Technique)  and  CPM  (Critical 
Path  Method).  [Ref.  11:  23]  To  even  further  quantify  the 
development  process,  the  number  of  modules  within  the  entire 
process,  the  number  of  statements  per  module,  and  the  cost 
per  statement  are  estimated.  [Ref.  20:  13]  Productivity  is 
the  critical  input  to  this  methodology.  The  major  drawback 
is,  however,  that  productivity  varies  greatly  between 
organizations  and  individuals. 

The  micro  approach  can  work  well  on  small  projects  where 
there  is  little  detail  involved  and  few  programmers  are 
required.  Troubles  develop  when  the  program  being  developed 
involves  large  volumes  of  detailed  specifications  and  hundreds 
of  thousands  of  lines  of  source  code. 

When  using  traditional  methodologies,  most  errors  in  cost 
estimation  are  a  result  of  underestimating  size,  sometimes  by 
as  much  as  a  factor  of  three.  This  is  usually  the  result  of 
erroneously  relating  productivity  to  delivered  source  lines 
of  code.  In  addition,  it  is  common  to  find  a  productivity 
factor  that  has  a  standard  deviation  two  and  one  half  times 
greater  than  the  expected  value.  [Ref.  7:  2]  More  discussion 
concerning  productivity  will  be  accomplished  later  in  this 
chapter  as  well  as  in  Chapter  IV. 
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The  macro  approach  views  the  project  from  a  higher  level. 
Beginning  as  early  as  the  Systems  Definition  phase,  manage¬ 
ment  parameters  serve  as  inputs  to  the  methodology.  The 
inputs  can  be  used  to  generate  the  expected  life-cycle  curve 
of  manpower  versus  time.  As  the  project  progresses  and  the 
parameters  become  firmly  established,  the  life-cycle  curve 
can  be  updated.  Milestones  can  be  located  along  the  curve 
and  parallel  tolerance  curves  can  be  generated  to  indicate 
the  percentage  of  uncertainty.  Through  the  information 
presented  along  the  life-cycle  curve,  control  can  be  exer¬ 
cised  over  the  life-cycle  of  the  project.  The  key  to  this 
approach  is  that  the  curve  can  be  shown  in  terms  of  manage¬ 
ment  parameters:  manpower,  time,  and  effort.  [Refs.  11:  24, 
20:  130]  This  is  the  a-pproa.cn  that  will  be  presented  in 
this  study. 

C.  SOFTWARE  MYTHS 

Most  large-scale  software  development  projects  that  go 
astray  do  so  because  of  calender  overruns.  [Refs.  5:  14, 

26:  9]  Much  of  the  problem  with  overruns  can  be  traced  to 
myths  that  surround  software  engineering: 

Development  effort  is  the  product  of  people  and  time. 

Programmer  productivity  (source  statement',  per  unit  of 

work)  is  constant  and  can  be  set  by  management. 

Productivity  varies  directly  with  the  effort  applied. 

Men  and  months  (time)  are  interchangeable. 

[Refs.  5:  14,  16:  352,  17:  343,  20:  14] 
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1 .  Development  Effort 

The  assumption  that  development  effort  scales 
linearly  as  the  product  of  people  and  time  (Figure  3)  leads 
one  to  believe  that  time  can  be  arbitrarily  set  by  manage¬ 
ment  and  that  the  requisite  number  of  people  can  be  assigned 
to  achieve  the  desired  results.  As  will  be  shown  in  the 
following  chapter,  this  reasoning  can  lead  to  both  calender 
and  cost  overruns . 

2 .  Productivity 

Traditionally,  management  estimates  the  number  of 
source  lines  of  code  and  applies  a  historical  overall  pro¬ 
ductivity  rate  to  determine  a  man-year  number.  For  example: 


aiven : 

Source  Lines  of  Code  (Ss)  =  200,000  lines  of  code 
(estimate) 

Productivity  (PR) 

( historical ) 


Total  Source  Lines  of  Code 
Total  Effort 


=  10C0  Ss/MY  (man-years) 


therefore: 

,  -pc  .  , - \  200,000  Ss  _  onn  wV 

Development  effort  (u)  =  ]_ q 0 q- s's7mY  "  200  MY 


Lawrence  Putnam,  during  the  course  of  his  studies, 
performed  a  least  squares  best  fit,  using  data  taken  from 
over  four  hundred  projects  of  the  United  States  Air  Force's 
Rome  Air  Development  Center,  against  delivered  source  lines 
of  code  for  each  of  the  four  hundred  projects.  The  data 
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expressed  a  wide  range  in  system  size  (100  to  1,000,000+ 
source  lines  of  code),  project  duration  (one  month  to  6 
years+),  man-months  of  effort  (one  MM  to  20,000  MM),  average 
number  of  people  (one  to  several  hundred),  and  productivity 
(10  Ss/MM  to  several  thousand  Ss/MM) .  The  resulting  corre¬ 
lation  coefficient  after  performing  a  least  squares  best  fit 
to  productivity  (Ss/E)  versus  delivered  lines  of  source  code 
was  found  to  be  r  =  .033415,  thus  displaying  virtually  no 
correlation.  [Refs.  20:  29-30,  24:  37] 

However,  after  performing  further  least  squares  best 
fit  relations,  project  duration  in  months  versus  delivered 
source  lines  of  code  showed  r  =  .700256.  When  total  man- 
months  versus  delivered  source  lines  of  code  were  predicted 
linearly,  r  was  shown  to  equal  .853915.  When  a  least  squares 
best  fit  was  performed  for  the  average  number  of  people 
involved  in  the  development  effort  versus  delivered  source 
lines  of  code,  the  correlation  coefficient  showed  r  =  .30388. 
[Refs.  23:  29-30,  24:  88-30]  Although  standard  deviations 
proved  to  be  large,  three  of  the  variables  did  show  good 
correlation  to  delivered  source  lines  of  code.  Furthermore, 
it  was  shown  that  there  is  virtually  no  correlation  between 
productivity  and  delivered  source  lines  of  code  (Table  2). 

C.  E.  Walston  and  C.P.  Felix,  in  their  study,  began  a 
software  measurement  project  for  the  IBM  (International 
Business  Machines  Corporation)  Federal  Systems  Division  in 
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able  2 


Correlation  Coefficients  (r) 

(3ased  on  Least  Squares  3est  Fit  against  Delivered  Source 
Lines  of  Code  (DSLOC)) 


Correlation 
Coefficient  (r) 


Productivity 

0 .033415 

(Ss/E) 

Project  Duration 

0.700256 

Time 

Total  Effort 

(MM  or  MY) 

0.853915 

Ive  .  Number  of  People 

Involved  in  Development  0.80388 

Effort 
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1372.  They  found  twenty-nine  variables  that  had  an 
extremely  high  correlation  with  productivity.  [Ref.  28:  62] 

The  figures  concerning  these  variables  are  tabulated  in 
Appendix  A. 

3 .  The  Interchangeability  of  Hen  and  Months 

One  of  the  largest  problems  associated  with  software 
engineering  evolves  from  the  erroneous  utilization  of  the 
concept  of  the  man-month.  Because  cost  varies  with  the 
product  of  men  and  the  number  of  months  (time),  using  man- 
month  as  a  means  of  measuring  the  size  of  a  job  implies  that 
men  and  months  are  interchangeable.  Unfortunately,  they  are 
not.  Man-month  is  a  measure  of  effort.  "The  number  of 
months  of  a  project  depends  upon  its  sequential  constraints. 
The  maximum  number  of  men  depends  upon  the  number  of  inde¬ 
pendent  subtasks."  [Ref.  5:  25-26] 

If  an  appropriate  development  schedule  is  established 
at  the  outset  of  a  project,  satisfactory  work  can  be  rccom- 
plis'ned  within  the  allotted  time  by  the  assigned  programmers. 
[Ref.  11:  23]  Otherwise,  the  oft  quoted  Brooks'  Law  takes 
over:  "Adding  manpower  to  a  late  software  project  makes  it 

later."  [Ref.  5:  25] 

D.  SUMMARY 

Life-cycle  management  and  the  software  development  process 
offer  a  structured  means  for  planning,  developing  and 
controlling  the  software  project.  Traditionally,  the  resource 
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estimation  process  has  been  a  micro  approach.  This  is  an 
intuitive  approach  which  hinges  extensively  on  the  relation¬ 
ship  between  productivity  and  delivered  source  lines  of  code. 
Data  from  past  projects  indicates  that  no  correlation  exists 
between  the  two.  Another  erroneous  assumption  made  in  the 
software  engineering  field  is  the  use  of  man-month  as  a  mea¬ 
sure  of  the  size  of  a  project.  Man-month  is  a  measure  of 
effort.  Another  estimating  approach,  macro-estimating,  makes 
use  of  accessable  management  parameters:  time,  manpower,  and 
cost.  In  order  to  accurately  estimate  the  project  resource 
requirements,  the  various  software  myths  that  manifest  them¬ 
selves  in  the  more  traditional  approaches  have  to  be 
dismissed . 
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III.  THE  LIFE-CYCLE  MANPOWER  CURVE 


As  previously  shown,  the  software  development  process 
can  be  subdivided  into  sequential  and  overlapping  phases. 
These  phases  can  also  be  further  subdivided  into  steps .  The 
relationship  between  the  phases  within  the  system  development 
process  is  such  that  required  work  for  a  particular  phase 
cannot  begin  until  specific  work  in  an  earlier  phase  is  com¬ 
pleted.  The  phases  display  technological  interdependence. 
[Ref.  13:  156] 

The  software  development  process  also  displays  the 
traits  of  a  homogeneous  project.  The  development  process  is 
such  that  each  phase  has  at  least  one  technological  inter¬ 
dependence  tie  to  another  phase.  Otherwise,  each  phase 
could  be  considered  an  independent  process.  [Ref.  13:  156] 

A.  CHARACTERISTICS  OF  THE  RAYLEIGH  MODEL 

In  the  life-cycle  model  developed  by  Peter  V.  Norden 
during  a  course  of  study  he  conducted  between  1956  and  1964 
at  the  IBM  Development  Laboratories  in  Poughkeepsie,  New 
York  [Ref.  12:  219],  a  small  number  of  successive  phases  of 
work,  with  each  phase  being  based  upon  the  manner  in  which 
complex  technological  problems  are  approached,  are  mathe¬ 
matically  fitted  to  a  life-cycle  curve.  This  life-cycle 
curve  can  be  mathematically  represented  by  the  Rayleigh 
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equation,  a  mathematical  form  from  the  Weibull  family  of 
reliability  functions.  The  equation  that  describes  each 
phase  is: 

2 

y'  =  2Kate  a  (Figure  4) 

where 

y’  =  the  manpower  utilized  during  each  time  period 
(man-years/year  or  man-months/month)  or  the 
number  of  people  involved  in  the  activity  at  any 
given  instant  in  time. 

K  =  the  total  cumulative  manpower  (life-cycle  effort) 
utilized  upon  completion  of  the  project  (man-years 
or  man-months ) . 

a  =  the  shape  parameter.  This  governs  the  time 
required  to  reach  peak  manpower. 

t  =  the  elapsed  time,  in  years  or  months,  from  the 
start  of  the  cycle. 

[Ref.  13:  156-157] 

The  Rayleigh  curve  appears  to  retain  its  validity  only 
for  an  activity  which  requires  the  making  of  large  decisions. 

A  combination  of  phases  will  not  result  in  a  single  overall 
Rayleigh  curve.  [Ref.  14;  13]  This  principle  states  that 
the  summation  of  a  series  of  overlapping  Rayleigh  curves  will 
not  produce  another  Rayleigh  curve.  There  is,  however,  a 
significant  observation  that  is  termed  the  Software  Development 
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'Single  Cycle'  Phenomenon  that  ignores  this  additive  principle. 
The  phenomenon  is  such  that  the  process  of  software  develop¬ 
ment  yields  cycles  that  do  add  up  to  a  Weibull  shape.  This 
seems  to  imply  that  the  software  development  process  is  a 
homogeneous  prcblem  solving  effort,  even  though  the  effort  is 
broken  down  into  phases.  [Ref.  12:  225]  This  phenomenon  was 
first  noticed  by  Lawrence  Putnam,  then  with  the  U.S.  Army 
Computer  Systems  Command.  Its  validity  has  since  been  corro¬ 
borated  by  many  other  studies  (Table  3).  Further  mention  of 
the  Rayleigh  equation/curve  will  be  in  the  context  of  software 
development . 

Multiplying  the  Rayleigh  equation  by  the  labor  rate  con¬ 
verts  it  to  a  cost  function.  Integrating  the  equation  over 
time  (Figure  5)  produces  cumulative  effort  and  cost  of  any 
time,  [Refs.  13:  153,  20:  5] 

.2 

y  =  K(i  -  e“at  ) 

and  taking  the  derivitive  of  the  Rayleigh  equation  (Figure  6) 

2  9 

y"  =  2Kae~at  (1  -  2at^) 

yields  the  change  in  the  total  effort  at  any  time.  [Ref.  13:158] 

The  Rayleigh  equation  is  expressed  in  terms  of  management 
parameters,  in  this  case,  time  and  effort,  which  are  necessary 
for  a  macro-methodology.  These  management  parameters  can  be 
further  expressed  in  terms  of  manloading  and  cash  flow  rates, 
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Table  3 


A  Sampling  of  Those  Who  Have 
Found  Evidence  of  Rayleigh-Like  Behavior 
[Ref. 


Investigator 

50  Army  Computer  Systems 
Command  (CSC)  Systems 

Apollo -Gemini 

MSA  System 

Electronics  Systems  Division 
(ESD) ,  USAF 

Defense  Log  Mgt  Agency 

Hughes  Aircraft 

GTE 

Apollo-Draper  Labs 
So.  Cal.  Edison 

General  Electric  Factory 
Control  (MICS) 

Wolverton's  Data 

Joel  Aron  and  IBM  Yorktown 

Riordan's  Dynamic  Model 


20:  32-33] 

Application 

Business 

Very  Large  Real-Time 
Mixed  (10-100  MY) 

3 

Imbedded  (C  ,  Wpns  Sys) 

Business  (Logistics) 
Mixed 

Real-Time  Telecomm 

On  Board  Software 

Small  On-Line  Customer 
Information  System 

Medium-Size  Process 
Control  System 

3 

Large  Aerospace  and  C 

Large  System  Software 
and  Application 

General  Systems 
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Figure  6 

Change  in  Manpower  Utilized 
[Ref.  13:  158] 
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1 


and  cumulative  effort  and  cost.  In  addition,  project 
delivery  schedules,  in  terms  of  project  milestones,  can  be 
empirically  located  on  the  curve. 

It  has  been  determined  that  the  shape  parameter,  'a', 
is  related  to  software  development  time  such  that 


where 

t^  =  development  time 

Mathematically,  t^  is  the  time  that  the  Rayleigh  curve 
reaches  a  maximum.  It  has  been  empirically  demonstrated 
that  this  is  essentially  the  time  that  a  system  becomes 
operational,  the  development  time.  [Refs.  17:  352-A,  20:  17] 
For  purposes  of  this  study,  it  will  be  assumed  that  t^  equals 
the  development  time  for  a  system. 

The  relationship  between  development  time,  t^,  and  the 
Rayleigh  equation,  and  cumulative  manpower,  K,  and  the 
Rayleigh  equation  are  graphically  demonstrated  in  Figure  7 
and  Figure  8. 

It  is  also  interesting  to  note  that,  in  Figure  5,  thirty- 
nine  percent  of  the  total  effort  utilized  takes  place  during 
the  first  quarter  of  the  phase.  Seventy-eight  percent  of 
the  total  effort  utilized  occurs  during  the  first  43.5  percent 
of  the  phase.  These  figures  point  out  the  realistic  time  and 
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MAN- TERRS  UTILIZED 


TIME  (TEARS; 


Figure  8 


Change  in  Manpower  versus  Constant 
[Ref.  13:  159] 


Time-To-Peak 

f 
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manpower  requirements  after  development  time  for  such  factors 
as  maintenance,  modifications,  and  continued  program 
management . 

3.  EFFECT  OF  SYSTEM  NOISE  AND  RANDOM  BEHAVIOR 

One  hundred  and  seventy-four  time  history  data  points 

of  thirty  eight  different  systems,  taken  primarily  from  the 

U.S.  Army  Computer  Systems  Command,  National  Security  Agency, 

and  IBM  -  NASA,  were  normalized,  in  order  to  make  the  ranges 

comparable,  and  plotted.  Lawrence  Putnam  fitted  the  best 

Rayleigh  curve  to  the  data,  along  with  a  ninety  percent 

confidence  interval,  with  the  resulting  coefficient  of 
2 

determination,  r  ,  equal  to  .7744  (Figure  9). 

It  is  quite  evident  that  there  is  considerable  scatter 
in  the  data.  One  must  consider  that  the  process  is  subject 
to  the  laws  of  probability,  due  to  less  than  perfect  manage¬ 
ment,  crises  will  appear  and  the  size  and  solution  become 
the  probabilistic  factor.  In  addition,  it  can  be  reasonably 
assumed  that  management  did  not  respond  to  project  require¬ 
ments.  Also,  data  is  not  necessarily  recorded  in  a  careful, 
precise  manner.  [Refs.  20:  19,  24:  74] 

What  allows  the  Rayleigh  equation  to  be  such  a  powerful 
management  tool  is  that,  even  with  considerable  scatter, 
development  time  can  be  determined  with  an  uncertainty  less 
than  three  percent  and  that  total  effort  can  be  determined 
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with  less  than  nine  percent  uncertainty.  It  is  now  obvious 
that  despite  noise  in  the  system,  management  parameters  can 
be  accurately  determined. 


C.  DIFFICULTY  CONCEPTS 

2 

The  ratio  k/t^  demonstrates  a  significant  relationship 
to  the  Rayleigh  equation.  The  variable  dimensions  of  this 
ratio  reflect  force,  the  time  rate  of  change  of  momentum. 
[Refs.  16:  350,  22:  19]  3y  linearizing  the  Rayleigh  equation 
through  the  process  of  logarithms 


Log ( y ' / t ) 


LogCK/t^2 ) 


and  plotting  the  equation  in  terms  of  manpower  applied  to  a 

2 

system  over  time  squared,  with  LogCK/t^  )  being  the  inter- 
2 

cept  and  1/(2  t^  )  the  slope,  a  straight  line  is  produced. 

Putnam  performed  this  operation  for  some  one  hundred  systems 

2 

and  found  that  the  argument  of  the  intercept,  K/t^  ,  reflec¬ 
ted  system  difficulty.  Those  systems  considered  easy  to 
develop  had  low  intercept  values  and,  conversely,  those 
considered  more  difficult  to  develop  had  high  intercept 
values  (Figure  10).  In  terms  of  the  management  parameters, 
it  is  evident  that  cumulative  manpower  is  directly  propor¬ 
tional  to  system  difficulty  while  development  time  is 
inversely  proportional  to  system  difficulty.  In  other  words, 
system  difficulty  reflects  programming  effort  and  the  time 
required  to  produce  the  system.  [Ref.  16:  350,  20:  35-36, 

22:  20] 
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Professor  George  J.  Fix,  of  Carnegie-Mellon  University, 


shows  that  the  dependence  of  the  system  difficulty,  D,  is 
such  that  D  is  a  function  of  time,  cumulative  manpower,  and 
cn-'nand  manpower. 

D  =  D(t,y,y ' ) 

This  implies  that  difficulty  increases  with  the  number  of 
people  involved  in  the  activity,  both  on-hand  and  cumulative, 
and  time.  [Ref.  8:  363] 

1 .  Feasible  Region 

One  can  visualize  a  feasible  software  region  based  on 
development  time  and  life-cycle  man  years  (Figure  11).  A 
system  can  span  from  a  life-cycle  man-year  of  one  to  almost 
any  given  total  number  of  life-cycle  man-years.  The  develop¬ 
ment  time  can  range  from  one  month  to  ten  years  or  more. 

For  large  systems,  though,  bounds  must  be  established,  there¬ 
by  creating  a  development-feasible  region.  Development  time 
can  be  limited  from  two  to  five  years:  five  years  being  an 
economic  upper  bound,  two  years  reflecting  the  lower  limit 
due  to  limitations  on  manpower  buildup.  [Ref.  16:  351, 

20:  37,  24:  115] 

Frederick  Brooks  alludes  to  this  lower  bound  by  citing 
V.A.  Vyssotsky's  estimates  that  "a  large  project  can  sustain 
a  manpower  buildup  of  30  percent  per  year."  [Ref.  5:  179] 

Norden's  equation 

.2 

y'  =  2Kate”at 


1 

holds  to  this  principle  when  the  development  time  is  equal 
to  or  greater  than  two  years.  [Ref.  22:  23]  The  manpower 
buildup  invokes  Brooks'  intercommunication  law  for  those 
projects  where  the  parts  must  be  separately  coordinated  with 
the  other  parts.  This  law  states  that  effort  increases  as  a 
function  of  n(n-l)/2.  By  adhering  to  this  law,  "three 
workers  require  three  times  as  much  pairwise  intercommunica¬ 
tion  as  two;  four  require  six  times  as  much  as  two." 

[Ref.  5:  18]  Lawrence  Putnam  rationalizes  this  lower  limit 
even  more  plainly.  He  says  that  large  software  projects 
less  than  two  years  in  duration  cannot  be  managed  "without 
heroic  measures."  [Refs.  16:  351,  22:  24] 

By  portraying  the  feasible  region  in  three  dimensions 

through  the  process  of  adding  a  new  axis  reflecting  system 
2 

difficulty,  k/td  ,  a  difficulty  surface  is  created  (Figure 
12).  It  should  be  noted  that  just  as  in  Figure  13,  as 
development  time  is  decreased,  difficulty  increases. 

2 .  Difficulty  Gradient 

Systems  tend  to  fall  on  lines  which  correspond  to  a 
constant  degree  of  difficulty  on  the  difficulty  surface. 

This  constant  difficulty  can  be  expressed  as 

K/td3  ~  | VD | . 

This  difficulty  gradient  reflects  the  organizational  capa¬ 
bility  while  doing  that  type  of  work  for  which  the  constant 

47 


w 


10,000 

4000 

K 

1,000 

A 

S\vDif  ficulty 

\Surface 

td  (years) 

Figure  12 

Effort-Time-Difficulty  Surface 


was  derived.  [Myers:  Ref.  30]  As  system  size  increases, 
development  time  also  increases  in  order  to  maintain  a 
constant  magnitude  of  7D .  [Ref.  15:  352] 

Putnam  found,  through  studying  all  the  systems  of 
the  U.S.  Army's  Computer  Systems  Command,  that  if  a  system 
is  entirely  new,  designed  and  coded  from  scratch  and  con¬ 
taining  many  interfaces  with  other  systems,  |  7D  j  =7.3.  If 
a  system  is  a  new  stand-alone  system,  [ 7D j  =14.7.  If  the 
system  is  rebuilt  from  existing  systems  where  large  segments 
of  logic  and  code  exist,  j  7D i  =  26.3.  Other  data  from  IBM 
and  the  Rome  Air  Development  Center  has  shown  that  for  what 
Putnam  calls  a  Composite  I  system,  one  which  consists  of 
independent  subsystems  which  reflect  few  interactions  and 
interfaces,  as  well  as  subsystem  development  occurring  with 
considerable  overlap,  | 7D j  =  55.0.  For  a  Composite  II 
system,  which  is  similar  to  a  Composite  I  but  with  minimal 
vice  few  interactions  and  interfaces,  and  with  subsystem 
development  occurring  essentially  in  parallel,  \ 7D |  =  89.0. 
Putnam  does  note  that  as  more  data  becomes  available  for 
different  classes  of  systems,  more  constants  are  likely  to 
emerge.  [Refs.  15:  352,  22:  3,  24:  154] 

The  values  of  the  difficulty  gradient  for  a  particu¬ 
lar  type  of  system  will  vary  between  software  houses.  This 
variance  is  based  on  the  average  skill  level  of  the  software 
house's  analysts,  programmers,  and  management.  For  a 
particular  kind  of  work,  the  values  of  the  difficulty  gradient 


reflect  a  learning  curve  for  the  software  house.  [Ref.  15: 
352]  Because  of  the  skill  variance  and  learning  attributes, 
one  can  expect  an  uncertainty  of  fifteen  percent  for  the 
base  gradient  values  expressed  in  the  previous  paragraph. 
[Ref.  24:  154] 

D.  PATTERNS  OF  MANLOADING 

There  is  a  myriad  of  possible  manloading  patterns.  For 
example,  they  can  be  rectangular,  trapezoidal,  triangular, 
or  just  about  any  geometric  shape  one  can  think  of.  Unfor¬ 
tunately,  the  perceptual  manpower  needs  of  the  project  may 
not  reflect  accurately  the  real  needs.  "If  management 
responds  promptly  to  the  perceived  needs  of  the  ongoing 
project,  the  manpower  loading  pattern  will  resemble  one  of 
the  large  number  of  Rayleigh-Norden  curves  possible." 

[Ref.  20:  25] 

For  the  example  as  portrayed  in  Figure  13,  the  rectan¬ 
gular  manloading  pattern,  perhaps  the  simplist  for  the 
manager  to  implement,  is  shown  plotted  against  a  Rayleigh 
pattern.  By  applying  the  concept  of  the  homogeneity  of 

t 

systems  development,  additional  personnel  cannot  be  judi¬ 
ciously  applied  to  the  project  until  the  initial  work  is 
completed.  The  rectangular  approach  results  in  initial 
wasted  effort,  a  lack  of  effort  when  critically  needed,  and 
extra  effort  toward  the  end  of  the  project.  Because  of  the 
lack  of  effort,  during  the  critical  periods,  schedule 


Slippage 


Time 


Figure  13 

Rectangular  Manloading  versus  Rayleigh  Manioading 

[Ref.  20:  26] 


slippage  results  and  further  additional  effort  is  reouired 
at  the  end  of  the  project.  This  additional  effort  continues 
at  the  maximum  manpower  level,  thus  compelling  the  project 
to  continually  impose  a  maximum  cash  flow  rate  and  probably 
forcing  a  cost  overrun.  If  Brooks'  Law  is  adhered  to,  this 
additional  manpower  will  not  keep  the  project  on  schedule. 

Correctly  applying  manpower  involves  projecting  an 
expected  Rayleigh-Norden  curve  and  setting  control  limits, 
based  on  the  uncertainty  of  the  initial  data.  As  more 
information  concerning  manpower  becomes  available,  the  curve 
is  adjusted  to  fit  reality.  The  project  manager  is  afforded 
the  luxury  of  being  able  to  project  manpower  needs,  update 
his  needs,  and  control  the  effort. 

E.  DETERMINATION  OF  MAJOR  MILESTONES 

Major  milestones  are  located  empirically  along  the 
Rayleigh  curve  based  upon  the  coupling  of  life-cycle  sub¬ 
cycles  to  the  overall  curve.  [Ref.  20:  117]  Table  4  shows 
the  milestones  derived  by  Putnam  from  data  from  the  U.S. 

Army  Computer  Systems  Command.  The  figures  in  Table  4 
display  quite  a  range;  however,  given  this  range,  should  a 
project  exceed  the  maximum  time  for  a  particular  milestone, 
it  should  be  quite  evident  to  the  project  manager  that  there 
is  a  problem  with  the  project  that  requires  attention.  The 
project's  not  meeting  the  minimum  time  should  be  a  signal  to 
the  project  manager  that  either  he  has  an  exceptional  team. 
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Table  4 


Times  of  Major  Milestones 
[Refs.  20:  71,  21:  140] 


Event 

Design  Certification 
First 
Expected 
Last 


t/t 


0.235 
0.433 
0 . 613 


Systems  Integration  Test 
First 
Expected 
Last 


0.550 

0.660 

0.753 


Prototype  Evaluation  Test 
First 
Expected 
Last 


0.613 
0 .300 


0.990 


Start  Installation/Extension 
First 
Expected 
Last 


0.513 

0.930 


1.250 


MOTE:  There  is  a  .90  probability  that  t/t.  will  lie 

between  first  and  last  for  a  particular  milestone. 
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his  planning  was  not  accurate,  or  something  was  accomplished 
in  a  cursory  manner.  It  has  been  shown  through  data  from 
several  hundred  systems,  reflecting  various  development 
environments,  that  the  relative  occurrence  of  the  four 
milestones  is  very  stable,  with  respect  to  the  expected 
value,  in  most  organizations  and  environments.  [Ref.  21:  140] 
It  is  important  to  remember  that  both  the  development 
time  and  the  milestones  are  the  most  sensitive  elements  in 
the  system  development  process.  Milestones  scale  in  a 
linear  fashion;  thus,  if  one  is  late  meeting  a  milestone,  he 
should  expect  to  be  late  on  succeeding  milestones .  Once 
behind,  the  project  manager  is  not  afforded  the  luxury  of 
being  able  to  catch  up;  "adding  manpower  to  a  late  software 
project  makes  it"  later."  [Ref.  5:  25]  Realistic  milestones 
must  be  set -at  the  beginning  of  the  project.  [Ref.  20:  71] 
Determining  the  major  milestones  not  only  aids  the  project 
manager  by  functioning  as  a  planning  tool,  but  also  is  a 
means  for  measuring  actual  accomplishment.  [Ref.  21:  140] 

F.  SYSTEM  SIZE  VERSUS  THE  LIFE-CYCLE  CURVE 

The  relationship  between  development  effort  and  life 

cycle  effort 
> 

E  =  .  4K 


holds  true  for  large  systems,  those  systems  with  more  than 
75,000  source  lines  of  code.  This  relationship  increases  in 
a  non-linear  fashion  as  system  size  decreases. 
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For  snail  systems,  those  with  less  than  18,000  source 
lines  of  code,  the  life-cycle  curve  closely  approximates  the 
curve  for  Che  Design  and  Coding  phase  (Figure  14).  Because 
there  is  very  little  system  overhead,  the  development  time, 
t.,  is  near  the  end  of  the  curve.  In  small  systems,  the 
life  cycle  curve  reaches  a  peak  at 


t,//6  [Ref.  20  :  75  ] 
d 


The  equation  for  the  curve  is 


y' 


[Ref.  21:  175] 


In  the  range  of  18,000  to  75,000  source  lines  of  code, 
the  overhead  support  activities  (documentation,  integration, 
testing,  maintenance,  and  management  activities)  rapidly 
increase.  Throughout  the  range  of  this  transition  zone,  the 
life-cycle  curve  expands  from  approximating  the  design  and 
coding  curve  to  the  full  life-cycle  curve. 

This  range  of  system  size  requires  an  additional  para¬ 
meter  in  the  solution  process  which  makes  the  solution 
extremely  complicated.  The  solution  involves  complex 
engineering  mathematics  and  is  well  beyond  the  scope  and 
intent  of  this  study;  however,  the  solution  has  been  auto¬ 
mated  and  is  included  in  the  SLIM  (Software  Life  Cycle 

Model)  software  estimation  program.  SLIM  and  its 
functions  will  be  discussed  in  Chapter  V. 
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Manpower 


G.  SUMMARY 


The  curve  resulting  from  the  Rayleigh  equation 


y' 


9  o 

K  ^  /2V 

— tt  t  e 


can  be  used  to  represent  the  life-cycle  of  a  software  project. 
Even  though  system  noise  and  random  behavior  can  be  expected, 
time  and  manpower  can  be  estimated  with  uncertainties  less 
than  three  percent  and  nine  percent  respectively.  Linearizing 
the  Rayleigh  equation  results  in  the  ability  to  determine 
system  difficulty.  The  creation  of  a  three  dimensional  project 
feasibility  area  offers  the  ability  to  visualize  a  difficulty 
gradient  reflecting  organizational  capability  for  a  particu¬ 
lar  type  of  work.  Based  on  empirical  data,  project  mile¬ 
stones  can  be  located  along  the  Rayleigh  curve  which  can,  in 
turn,  be  valuable  as  a  measure  of  project  control. 
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IV.  SOFTWARE  ECONOMICS:  THE  SOFTWARE  EQUATION 

In  the  previous  chapter,  equations,  relationships,  and 
variables  were  introduced  that  allow  the  project  manager  to 
plan  and  control  the  software  development  process.  Two  key 
variables,  life-cycle  effort,  K,  and  development  time,  t^, 
afford  the  project  manager  the  ability  to  generate  both  the 
instantaneous  and  cumulative  manpower  requirements,  as  well 
as  the  development  costs,  through  the  application  of  the 
Rayleigh  equation. 

This  chapter  serves  to  show  the  relationship  of  K  and 
td  to  the  software  development  process.  This  relationship 
is  expressed  in  a  very  powerful  management  tool:  the 
software  equation.  In  addition,  the  answer  to  the  fourth 
management  question 

What  are  the  risks? 

will  be  addressed  through  the  development  of  risk  profiles. 


A.  THE  SOFTWARE  EQUATION 

The  software  equation,  a  mathematical  relationship 
developed  by  Lawrence  Putnam,  is  an  extremely  powerful  tool 
for  planning  and  evaluating  the  development  effort  of  the 
software  life-cycle  (Figure  15).  The  software  equation  is 
expressed  as: 


Ss  = 


Ck  K1/3  t 


4/3 
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igure 


where 

Ss  =  expected  number  of  source  lines  of  code. 

Ck  =  technology  constant. 

t_j  =  development  time  (years). 

K  =  life-cycle  effort  (man-years). 

The  mathematical  development  of  the  software  equation  will 
not  be  covered  in  this  study:  however,  an  explanation  can 
be  found  in  reference  9:  page  328,  reference  15:  page  353, 
reference  17:  page  352-B  and  reference  18:  page  108. 

3y  rearranging  the  software  equation  and  applying  a 
factor  of  .4  to  reflect  the  development  effort  being 
approximately  the  first  forty  percent  of  the  life  cycle 
curve,  the  development  effort  can  be  determined: 


E  =  .  4K 


,  4  (— )  3 
Ck; 


1 


3y  applying  the  burdened  labor  rate,  the  equation  can  be 
converted  to  a  cost  function: 


Development  Cost  =  ($/M-Y) 


.4 


/Sss  3 
kCk; 


[Refs.  19:  304,  20:  7] 

I 
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1 .  Technology  Constant 

The  most  difficult  variable  in  the  software  equation 
to  grasp  is  the  technology  constant.  The  technology  constant 
is  : 

"the  state  of  technology  being  applied  to  the  software 
development;  the  environment  in  which  the  development 
takes  place;  the  development  equipment  available,  which 
in  turn  affects  program  turnaround  and  the  time  needed 
for  debugging  and  testing;  the  extent  to  which  modern 
programming  practices  are  incorporated  into  the  develop¬ 
ment  project."  [Ref.  20:  40] 

The  technology  constant  for  a  firm  can  be  calculated 
given  the  delivered  source  lines  of  code,  development  effort, 
and  development  schedule  of  completed  projects.  For  a  new 
project,  values  calculated  from  other  projects  completed  by 
the  particular  software  developer  can  be  compared  against 
that  which  is  estimated  for  the  new  project  to  determine  if 
the  new  constant  is  reasonable.  It  is  important  to  remember 
that  a  technology  constant  derived  for  a  particular  software 
house  is  not  necessarily  indicative  of  the  technology  con¬ 
stant  for  another  software  house. 

John  E.  Gaffney,  of  IBM-Manassas ,  using  data  from 
software  development  projects  performed  at  IBM,  Manassas, 
Virginia,  found  a  correlation  coefficient,  r,  of  -0.72 
between  the  technology  constant  (Gaffney  refers  to  the  tech¬ 
nology  constant  as  the  development  constant)  and  code  com¬ 
plexity.  In  his  study,  code  complexity  is  based  on  the 
proportion  of  conditional  jumps  in  the  code.  This  infers 
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that  51.3  percent  of  any  variation  in  the  technology  con¬ 
stant,  Ck,  can  be  explained  by  the  measure  of  code  com¬ 
plexity.  [Ref.  9:  330] 

2 .  Trade-off  Law 

The  equation  for  development  effort 


reflects  the  power  of  the  software  equation:  the  trade-off 
law . 

By  improving  the  development  environment,  Ck  increases, 
thus  decreasing  the  development  effort  required  to  complete 
a  project.  By  taking  out  the  "whistles  and  bells"  from  the 
system  and  reducing  the  number  of  source  statements  to,  for 
example,  .95  Ss,  cost  will  be  reduced  to  eighty-six  percent 
of  the  original  cost.  [Ref.  20:  7]  Given  a  specific  environ¬ 
ment  with  source  lines  of  code  and  technology  held  constant, 

..  Constant 

-<  =  - 4 - 

*d 

effort  decreases  as  the  inverse  of  development  time  to  the 
fourth  power.  With  a  small  change  in  time,  a  quantum  change 
in  effort  results  (Figure  15).  "In  software  development, 
time  is  money.  By  giving  a  little  (time),  we  can  save  a  lot 
(of  money)."  [Ref.  20:  43] 
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Development  Effort,  Time,  Technology  Constant  Tradeoff 

[Ref.  9:  832] 


If  one  is  able  to  increase  his  technology  constant 
through,  for  example,  the  purchase  of  a  development  computer 
and  this  increase  is  such  that 

Ck(naw)  =  1.3  Ck(old) 

the  manpower  savings  can  pay  for  the  development  computer. 
Since 

Development  Cost(new)  =  — i-*-  Development  CostCold 

1.3J 

=  45.5%  Development  CostCold) 

A  54.5  percent  savings  (100.0  percent  -  45.5  percent)  on  an 
old  development  cost  of  $1  Million  would  equal  $545,000. 

This  savings  would  certainly  be  enough  to  buy  a  powerful 
development  computer.  [Ref.  19:  804-805] 

3y  invoking  the  tradeoff  law,  the  project  manager  can 
effect  substantial  savings  by  improving  his  development 
environment,  keeping  the  system  site  as  small  as  practical, 
and  by  scheduling  as  much  time  as  reasonably  allowable  for 
the  development  effort.  [Ref.  19:  804] 

3.  SIZING  THE  PROJECT 

In  order  to  initiate  development  planning  and  control, 
the  system  size  must  be  determined  early  in  the  system 
definition  phase  (point  1,  Figure  15).  Because  the  actual 
design  functions  have  yet  to  be  initiated,  the  project 
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manager  has  access  only  to  broad  estimates  of  the  system 
size;  yet,  this  is  enough  to  allow  him  to  determine  the 
basic  economic  feasibility  of  the  project.  There  will  be  a 
tremendous  degree  of  uncertainty  in  the  early  sizing,  but 
this  is  to  be  expected.  To  demand  pinpoint  accuracy  during 
system  definition  is  an  effort  in  futility. 

As  the  system  definition  and  functional  design/ 
specification  phases  progress,  more  is  known  about  the 
system  and  estimates  of  system  size  become  more  accurate 
(points  2  and  3,  figure  15).  3y  the  time  that  detailed 
design  begins,  uncertainty  can  be  reduced  to  within  the 
limits  of  engineering  accuracy.  [Ref.  21:  191] 

1 .  FERT  Sizing  Technique 

Sizing  wili  be  performed  using  PERT  (Program  Evalua¬ 
tion  and  Review)  sizing  techniques.  Expected  system  size  is 
determined  by: 

_  -  a  +  ■*  m  +  b 

exceeded  _s  =  - - - 

o 


where 

a  =  smallest  possible  system  size 
m  =  most  likely  system  size 
b  =  largest  possible  system  size. 

This  equation  is  an  estimation  of  the  expected  value  of  a 
Beta  distribution  and  skews  the  value  toward  the  most 
uncertain  side. 
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For  the  first  sizing  attempt,  during  the  system  defi¬ 
nition  phase,  such  a  wide  range  of  uncertainty  exists  that 
a  simple  average  will  suffice  such  that 

Expected  Ss  =  —  -4j- ~D 

The  standard  deviation  is  determined  by  the  standard 
deviation  of  the  Beta  distribution  of  system  sizes: 


This  is  the  range  in  which  93  percent  of  the  values  are 
expected  to  occur  divided  by  six.  Therefore,  the  system 
size  will  equal 

Ss  =  Expected  Ss  +  oSs. 

Statistically,  there  is  a  fifty  percent  chance  that  the 
system  size  will  fall  on  either  side  of  the  expected  system 
size.  There  will  be  a  sixty-eight  percent  certainty  of  the 
system  being  within  one  standard  deviat  jn  of  the  expected 
system  size,  ninety-five  percent  certainty  that  the  system 
size  will  be  within  two  standard  deviations,  and  39  percent 
certainty  that  the  system  size  will  be  within  three  standard 
deviations . 

The  sizing  process  is  demonstrated  in  the  following 

example . 


66 


Early  in  the  system  definition  phase,  the  project 
manager  is  given  the  following  estimates  of  system  sice: 


Function 

a 

m 

b 

Module 

1 

76000 

30000 

117000 

Module 

2 

37  000 

112000 

136000 

Module 

3 

63000 

99000 

112000 

Using  the  PERT  sizing  technique,  the  following  expected 
values  and  standard  deviations  are  computed: 


Function 

Expected  Ss 

crSs 

Module 

1 

92167 

68  3  3 

Module 

2 

111833 

3167 

Module 

_3 

96167 

7167 

System 

300,167 

128  36 

Expected  Ss( total)  is  the  summation  of  the  expected  Ss  of 
each  module.  oSs(total)is  equal  to 


The  results  indicate  that  there  is  a  sixty  eight 
percent  certainty  that  the  system  size  will  be 


30G167  +  12836  source  lines  of  code 


The  numbers  are  rough  estimates  and  the  variance  is 
extremely  large;  however,  the  project  manager  now  has 
reasonable  figures  within  which  he  can  plan. 

During  the  Functional  design  phase,  the  project 
manager  receives  more  detailed  estimates  based  on  further 


modularization 

of  the  system. 

Function 

a  m 

b 

Module 

1A 

32075  37175 

43900 

Module 

13 

29550  32429 

38475 

Module 

1C 

18225  31582 

40900 

Module 

2A 

4137  5  53450 

61248 

Module 

23 

39950  47120 

55353 

Module 

3A 

27210  39805 

43715 

Module 

3B 

24900  31625 

35775 

Module 

3C 

23875  29375 

34345 

PERT  sizing  computations  reveal: 

Function 

Expected  Ss 

aSs 

Module 

1A 

37446 

1971 

Module 

IB 

32957 

1488 

Module 

1C 

30909 

3779 

Module 

2  A 

52821 

3229 

Module 

2B 

47297 

2  567 

Module 

3A 

38378 

27  51 

63 


Module  3B 


31136 


1813 


Module  3C  29287  1745 

System  300291  7162 

Although  the  level  of  derail  is  still  not  verv  great, 
an  even  more  refined  expected  number  of  source  statements  is 
now  available.  What  is  even  more  important  is  that  by 
further  modularizing  the  system,  the  standard  deviation  is 
substantially  decreased;  in  this  example,  the  uncertainty  is 
reduced  by  more  than  forty-four  percent. 

C.  DEVELOPMENT  TIME/EF FORT  DETERMINATION 

Far  too  often,  the  development  time  for  a  project  is 
arbitrarily  established  by  management.  Because  the  develop¬ 
ment  process  is  so  time  sensitive, 

K  -  Constant 


setting  development  time  based  on  factors  external  to  the 
project  can  lead  to  unanticipated  and  unwanted  difficulties. 

For  example,  the  software  project  in  the  previous  section, 
in  order  for  it  to  be  ready  for  a  business  symposium,  has  a 
two  year  development  time  imposed  upon  it.  The  system  is 
a  new  stand-alone  system  with  the  following  parameters: 

Ck  =  10946 

Ss  =  300,000 
aSs  =  5385 
$ /MY  =  $50,000 
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Through  use  of  the  software  equation,  it  is  calculated 

that 

E  =  514.58  man-years 
Development  Cost  ($E)  =  $25,734,009 
This  resulting  effort  and  cost  is  ludicrous. 

By  plotting  the  software  equation  and  difficulty  gradient 
as  development  time  versus  system  size,  given  a  technology 
constant  of  10946  and  | VD [  =  14.7,  a  tradeoff  region  is 
developed  (Figure  17).  With  the  difficulty  gradient  imposing 
a  minimum  constraint,  it  is  obvious  that  the  system  cannot 
be  developed  in  two  years. 

By  using  the  tradeoff  region  or  substituting  the  diffi¬ 
culty  gradient 

K  =  | 7D |  td3 

into  the  software  equation, 

,33.3  1/7 

t  -  (  Ck  ) 

the  earliest  possible  time  that  the  development  can  be  com¬ 
pleted  is  2.315  years  or  33.8  months,  almost  ten  months 
longer  than  the  time  that  management  arbitrarily  set.  The 
system  difficulty  precludes  a  development  time  less  than 
33.3  months.  However,  the  project  can  be  accomplished  such 
that : 
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33.8  months 


K  =  327.83  man-years 
E  =  131.15  man-years 
$E  =  $6,557,723 

3y  increasing  the  development  time  by  almost  ten  months,  a 
74.5  percent  reduction  in  effort  and  development  cost  is 
achieved . 

3y  further  increasing  development  time  to  three  years, 
more  can  be  saved  in  terms  of  effort  and  development  cost: 

K  =  254.18  man-years 
E  =  101.67  man-years 
$E  =  $5,083,261 

The  application  of  the  software  equation  and  the  trade¬ 
off  law  provides  a  powerful  basis  for  a  usable  software 
economics  relationship.  This  will  allow  the  project  manager 
to  realistically  establish  time  and  resource  requirements 
with  respect  to  his  development  environment. 

D.  LINEAR  PROGRAMMING  SOLUTION 

Because  more  than  one  unknown  is  being  dealt  with  and 
management  constraints  can  be  applied  to  the  development 
process,  an  optimal  solution,  either  in  terms  of  minimum  or 
maximum  time,  can  be  reached  by  using  linear  programming 
techniques . 
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Constraints  which  can  be  applied  to  the  linear  pro¬ 


gramming  problem  are: 

Expected  source  lines  of  code 


maximum  peak  manpower 


minimum  peak  manpower 


maximum  difficulty  gradient 


delivery  time 


Ss  =  Ck 


K1/3t 


4/3 


K  t  ,  <  Je  y '  ( max ) 

Q  — 

K  rd  _<  ve  y'  (min) 

—  <  VD 
d 

t^  _<  contract  delivery  time 


budget 


$/MY(.4K)  <_  total  amt.  budgeted 

for  development 


with  the  objective  function  being  the  software  equation  and 
both  K  and  t^  being  the  decision  variables. 


Ss 


Ck  K1/3 


4/3 


Continuing  with  the  previous  example,  the  constraints 

are : 


| 7D [  =  14.7  (Stand-alone  system) 

Ss  =  300,000 

Management  has  realised  the  error  of  their  ways  and  has 
established  a  three  year  development  time  and  an  $8  million 
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development  budget.  It  has  also  been  determined  that  a 
minimum  of  thirty  people  and  a  maximum  of  eighty  people  will 
be  available  at  peak  manning.  Further  constraints  are: 


maximum  manpower  available  _<  80  people 

minimum  manpower  available  3  0  people 

maximum  time  <  3  years 

maximum  budget  _<  $8M 

In  order  to  fit  the  linear  programming  model,  the  con¬ 
straints  and  objective  function  must  be  linearized.  By 
applying  logarithms,  the  objective  function  and  constraints 
become : 

objective  function: 
minimize 

1/3  log  K  +  4/3  log  t^  =  log  Ss  -  log  Ck 
subject  to: 


1/3 

log 

K  +  4/3 

iog  td 

< 

300000 

-  log 

10946 

1/3 

log 

K  +  4/3 

iog  td 

> 

300000 

-  log 

10946 

log 

K  - 

3  log  td 

>  log 

14 

n 

•  / 

log 

K  - 

3  log  td 

<  log 

14 

.7 

log 

K  - 

iog  td  < 

log  (  /e 

80) 

log 

K  - 

iog  td  > 

log  (  i 

/e 

30) 

log 

*d  - 

i  log  3 

log 

K 

<  log  ((8000000/ 

'500000)  ( 

.4)) 
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Graphically  applying  the  objective  function  and  the 
constraints  results  in  Figure  18.  Because  the  constraint  on 
the  number  of  source  lines  of  code  is  graphically  parallel 
to  the  objective  function,  there  will  be  an  infinite  number 
of  solutions  with  the  minimum  time/maximum  cost  and  maximum 
time/minimum  cost  solutions  bounding  a  feasible  region  along 
the  source  lines  of  code  constraint.  In  this  particular 
example,  t^  and  D  limit  the  solution  and  affect  the  following 
optimal  solutions: 


t^( years ) 

K(MY) 

E  (MY) 

$E 

min 

time  2.82 

327.3 

131.2 

$6,557,723 

min 

cost  3.00 

254.2 

101.7 

$5,083,261 

The 

manpower  constraints 

do  not , 

in  this 

instance,  effect 

the  solution,  but  altering  the  manpower  constraints  could 
result  in  a  totally  different  optimal  solution. 

A  tradeoff  region  lies  between  t^  =  2.82  years/K  =  327.8  MY 
and  t^  =  3  years/K  =  254.2  MY  on  the  objective  function. 
Clearly,  by  altering  any  of  the  constraints,  new  optimal 
solutions  can  result.  Yet,  given  the  constraints  of  this 
particular  example,  the  solution  is  more  sensitive  to  develop¬ 
ment  time  as  the  difficulty  gradient  imposes  the  upper  bound 
and  cannot  be  changed. 
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E.  RISK  PROFILES 


The  life-cycle  curve  is  not  a  single  line,  but  a  line 
with  a  bandwidth  about  it  (Figure  9).  All  the  variables  of 
the  software  equation  are  subject  to  some  degree  of  uncer¬ 
tainty  and  the  project  manager  must  have  a  means  of  taking 
this  into  account  in  an  effort  to  develop  risk  profiles. 

Already,  a  degree  of  uncertainty  has  been  established 
for  the  difficulty  gradient  in  Chapter  III  [Ref.  24:  154]  and 
for  source  lines  of  code.  Allowing  for  a  standard  deviation 
of  fifteen  percent  of  the  base  value  of  the  difficulty 
gradient,  [VD|  =  14.7,  and  for  aSs  =  5985,  as  per  the  previous 
example,  the  following  equations  can  be  solved  similtaneously 
about  the  mean,  and  within  a|  7D  |  and  aSs: 

yl/3*  4/3  Ss 

~  Ck 

VD ! 

[Ref.  20:  59] 

By  solving  these  equations  several  thousand  times  on  a 

A  A 

computer,  K,  t^,  aK,  and  at^  can  be  determined. 

Management  has  decided  to  work  toward  the  minimum  cost 
solution 
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and,  after  performing  a  simulation,  arrives  at  the  following 
values : 

t^  =  3  years 
jtj  =  .25  years 
K  =  252.0  man-years 
jK  =20.4  man-years 

Risk  profiles  can  now  be  graphically  established  for  both 
development  time  and  effort  using  normal  probability  graph 
paper . 

Using  the  hypothetical  example,  to  establish  a  risk  pro¬ 
file  for  development  time,  the  expected  value,  36  months 
(three  years),  is  plotted  at  the  fifty  percent  probability 
level  (Figure  19).  3elow  this  plot,  at  the  sixteen  percent 
probability  level,  one  standard  deviation,  3  months,  is 
marked  off.  3ecause  the  scale  of  the  paper  straightens  out 
the  normal  probability  integral,  only  these  two  points  are 
required  to  plot  the  graph.  [Ref.  22:  34] 

The  risk  profile  for  development  time  shows  a  ninety 
percent  confidence  interval  between  32.2  months  and  37.3 
months.  The  project  manager  can  be  assured  that  there  is  a 
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Figure  19 

Risk  Profile:  Development  Time 
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Probability  That  Development  Time  Will  Be  Less  Than 


99  percent  certainty  that  the  project  will  not  exceed  forty- 
three  months,  barring  external  interruptions  to  the  existing 
development  environment. 

Likewise,  a  risk  profile  can  be  determined  for  life-cycle 
effort,  K,  (Figure  20)  and  given  an  average  burdened  cost, 
this  can  be  easily  converted  to  a  life-cycle  cost  risk  profile 
Also,  risk  profiles  can  be  developed  for  development  effort 
and  development  cost. 


F.  SUMMARY 

The  economics  of  software  can  be  expressed  through  the 
mathematical  relationship  known  as  the  software  equation: 


Ss 


:k  k 


1/3 


4/3 


The  software  equation  is  a  very  powerful  managment  tool 
which  mathematically  reflects  important  economic  and  be¬ 
havioral  characteristics  to  all  those  concerned  with  the 
software  project. 

The  software  equation  reflects  the  time  sensitivity  of 
the  development  process.  Time  cannot  be  changed  without 
changing  effort. 

Each  software  project  has  an  associated  minimum  develop¬ 
ment  time.  Completed  development  cannot  be  expected  to 
occur  prior  to  this  minimum  time.  Knowing  the  minimum  develop' 
ment  time  and  its  uncertainty  gives  the  project  manager  a 
framework  from  which  to  plan  and  control  the  software 
development  process. 
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Figure  20 

Risk  Profile:  Life-Cycle  Effort 


The  trade-off  law  is  an  extremely  powerful  tool  which 
offers  the  project  manager  the  opportunity  to  save  money  by 
allowing  more  time  for  the  development  process,  changing  the 
development  environment,  and  eliminating  the  "whistles  and 
bells"  from  the  project. 
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V.  SLIM:  AN  AUTOMATED  APPROACH 

A  methodology  which  permits  the  project  manager  to 
answer  the  four  management  questions 

Is  the  project  feasible? 

What  are  the  resource  requirements? 

How  long  will  it  take? 

What  are  the  risks? 

has  now  been  mathematically  shown.  Applying  the  techniques 
by  hand  is,  at  best,  a  tedious  and  time  consuming  chore. 

The  process  has  been  automated  by  Quantitative  Software 
Management,  Inc.,  and  is  available  through  American  Manage¬ 
ment  Systems,  Inc.  The  Department  of  Defense  has  taken  an 
interest  in  this  particular  methodology  and  has  contracted 
the  services  of  this  automated  software  estimation  package 
as  well  as  an  instructional  package  as  per  Government 
Contract  MDA903-81-D-0062  (Appendix  3). 

This  chapter  will  be  devoted  to  the  SLIM  (Software  Life 
Cycle  Model)  package,  what  it  does,  its  weaknesses,  and  what 
it  can  do  for  the  project  manager. 

SLIM  "is  a  versatile,  highly  flexible  software  system 
that  is  iesigned  to  help  software  managers  and  analysts 
estimate  the  cost,  manpower,  and  time  to  build"  software 
systems.  [Ref.  25:  1-1]  All  outputs  are  in  terms  of  usable 


management  parameters . 


SLIM  automates  three  functions  (Table  5) .  The  Estimate 
function  has  various  options  (Table  6)  which  allow  the  user 
to  design  the  system  development  process,  update  an  ongoing 
development  process,  and  validate  vendor  proposals. 

A.  SLIM  EXAMPLE 

Perhaps  the  easiest  method  to  fully  explain  SLIM  is  to 
demonstrate  the  power  and  flexibility  of  the  system  through 
an  example. 

1 .  Scenario 

The  software  project  'Thesis  Example'  is  a  rebuild, 
business  application,  system.  The  project  has  just  entered 
the  functional  design  phase.  The  project  manager,  in  order 
to  update  development  plans,  wishes  to  use  SLIM  given  the 
following  constraints: 

Development  time:  42  months 
Development  begins:  January  1983 
Maximum  budgeted  cost:  $5.5M 

Maximum  number  of  men  available  at  peak  manning:  60 
Minimum  number  of  men  available  at  peak  manning:  30 
Average  burdened  labor  rate  ($/MY):  $50,000 

Cost  of  Capital:  10% 

In  addition,  the  following  is  known  about  the  system 

development  environment: 

Percentage  of  on-line  development:  100% 

Percentage  of  the  development  computer  dedicated 
to  the  development  effort:  80% 
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able  5 


Calibrate 

Editor 

Estimate 

Bye 


SLIM  Functions 


Is  used  to  obtain  historical  data  from  the  user. 
This  data  will  be  translated  internally  into  a 
"State  of  Technology"  factor  for  the  user's 
organization.  It  is  then  used  to  calibrate  the 
model  to  the  way  a  particular  organization 
typically  develops  software. 

Allows  the  user  to  interactively  create  a  data 
file  describing  a  new  software  system. 

Is  used  to  obtain  cost,  schedule,  and  manpower 
estimates  once  a  data  file  has  been  built. 

Is  used  to  end  the  current  session. 
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able  6 


LINEAR  PROGRAM 


NEW  TIME 


DESIGN  TO  GOST 


PERT  SIZING 


TRADE-OFF  ANALYSIS 


SLIM  Options 


-  This  function  uses  the  technique  of 
linear  programming  to  determine  the 
minimum  effort  (and  cost)  or  the 
minimum  time  in  which  a  system  can 
be  built.  The  results  are  based  on 
the  actual  manpower,  cost,  and 
schedule  constraints  of  the  user, 
combined  with  the  system  constraints 
described  earlier  to  yield  a  con¬ 
strained  optimal  solution. 

-  SLIM  will  automatically  determine  the 
minimum  time  schedule  for  which 
development  of  your  system  is  feasible. 
This  function  may  be  used  to  set  an 
alternative  schedule  for  development. 

A  new  corresponding  cost  will  be 
provided . 

-  This  function  is  used  to  allow  the 
user  to  set  a  new  level  of  effort  and 
cost  for  development.  A  new  time 
schedule  will  be  generated. 

-  This  technique  is  used  to  generate 
the  best  estimate  of  total  source 
statements  and  the  associated  stan¬ 
dard  deviation. 

-  This  is  a  very  powerful  technique 
which  allows  the  user  to  compare  the 
costs  and  manpower  necessary  to  build 
a  system  over  various  time  scheudles. 
This  analysis  demonstrates  the  extreme 
time  sensitivity  of  developing  soft¬ 
ware  -  as  time  decreases,  the  costs 

go  up  dramatically.  Also,  a  minimum 
feasible  time  schedule  is  shown,  indi¬ 
cating  that  for  the  size  and  type  of 
system  is  shown,  indicating  that  for 
the  size  and  type  of  system  described, 
a  shorter  time  schedule  simply  cannot 
be  imposed  upon  it. 
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Table  6  continued- 


FRONT-END  ESTIMATES 


MAN LOADING 


CASHFLOW 


LIFE  CYCLE 


RISK  ANALYSIS 


3ENEFIT  ANALYSIS 


MILESTONES 


-  This  function  provides  low,  average, 
and  high  estimates  of  the  time  and 
effort  required  for  the  feasibility 
study  and  functional  design. 

-  This  function  is  based  on  a  monte 
carlo  simulation  of  total  manpower 
and  time.  Projections  of  the  mean 
number  of  people  (and  the  standard 
deviation)  on  a  month-to-month  basis 
are  provided.  These  projections  are 
based  on  an  optimal  application  of 
resources  throughout  development. 

-  This  function  is  based  on  a  Monte 
Carlo  simulation  of  manpower,  time, 
$/MY,  and  inflation  rate  to  provide 
projections  of  the  expected  cashflow 
on  a  month-to-month  basis  throughout 
development . 

-  This  function  provides  a  table  of 
expected  manpower  and  cashflow  over 
time  throughout  the  operations  and 
maintenance  phase. 

-  This  function  determines  the  proba¬ 
bility  of  developing  a  system  within 
a  specified  time  or  for  a  specified 
cost.  It  is  very  useful  for  strategic 
planning  purposes,  by  providing  the 
risk  associated  with  various  time  5 
cost  decisions. 

-  This  function  computes  the  benefit  of 
your  system  in  $/year  required  to 
amortize  the  cost  of  development  and 
maintenance .  It  is  based  on  the 
anticipated  economic  life  of  the 
system  as  well  as  the  average  rate  of 
return  for  your  organization. 

-  Based  on  a  predetermined  total  develop¬ 
ment  time,  this  function  provides  a 
realistic  schedule  for  the  major 
milestones  of  the  project. 
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Table  6  continued- 


CPU  USAGE 


DOCUMENTATION 


ALL  ANALYSES 


END 


-  This  function  provides  a  table  of 
expected  machine  usage  over  the  life 
cycle  of  the  system,  along  with  an 
estimate  of  total  machine  hours 
required  for  development. 

-  3ased  on  the  total  system  size  and 
data  from  hundreds  of  similar  soft¬ 
ware  systems,  a  range  of  expected 
pages  of  documentation  is  given. 

-  This  function  calls  all  of  the  above 
functions  automatically  except 

*new  time*  and  *design  to  cost*.  If 
a  complete  analysis  of  a  system  is 
desired,  it  is  recommended  that  you 
use  “new  time*  or  *design  to  cost* 
to  set  your  desired  schedule,  and 
then  call  *all  analyses*  for  a  com¬ 
plete  analysis. 

-  This  command  may  be  used  to  return 
to  the  SLIM  system  monitor. 
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Percentage  of  system  coded  in  a  high  order 
language  (HOL) :  100% 

HOL  used:  COBOL 

Percentage  of  the  target  machine's  memory 
utilized  by  the  system:  50% 

Percentage  of  real-time  code:  0.0% 

Technology  factor  that  has  been  calibrated:  9 

In  addition,  modern  programming  practices  will  be  used 
extensively  except  that  there  will  be  no  chief  programmer 
teams.  The  project  personnel  are  very  experienced  in  terms 
of  skill  and  familiarity  with  COBOL;  however,  they  have  only 
an  average  experience  with  the  development  computer  and  with 
a  system  of  this  size. 

The  technology  factor  was  derived  using  the  Calibrate 
function  and  historical  data.  The  difference  between  the 
technology  factor  and  the  technology  constant  will  be  dis¬ 
cussed  later  in  this  chapter. 

2 .  SLIM  Application 

Given  the  previous  information,  the  project  manager 
can  call  on  the  Editor  function  to  build  a  file  for  the 
project . 
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ED  I TOP 


THE  EDITOR  ALLOWS  THE  USER  TO  INTERACTIVELY  :ET  UP  A  MEM  DATA  FILE 
DESCRIBING  H  SOFTWARE  DEVELOPMENT  SYSTEM.  YOU  ''‘ILL  BE  PROMPTED  FOP  AlL 
information.  the  responses  you  provide  mill  be  used  to  determines 

•  P  THE  TYPE  HMD  DIFFICULTY  OF  YOUP  SYSTEM. 

•:2>  the  state  of  technology  being  applied  to  development,  »nd 

•  3'  COSTING  INFORMATION  AEGUT  YOUP  ORGANIZATION. 

ALL  INFORMATION  ‘.‘ILL  BE  SAVED  CM  FILE  FOR  LATER  UPDATES  OP  ACCES.  . 

OUTPUT  FILENAME'  THESIS 

ENTER  THE  TITLE  OF  THE  SOFTWARE  SYSTEM-  THESIS  EXAMPLE 
ENTER  START  DATE  • MMYY '  0133 

ENTER  THE  fully  BURDENED  LABOR  RATE  •  i  r«Y  .  AT  "OUR  ORGANISATION'  50000 

ENTER  THE  STANDARD  DEVIATION  OF  '.'OUR  lAEOR  PATE"  5000 

ENTER  THE  ANTICIPATED  INFLATION  RATE  AS  A  DECIMAL  FRACTION'  .1 

ENTER  THE  PROPORTION  OF  DEVELOPMENT  THAT  MILL  OCCUR  IN  ONLINE. 

INTERACTIVE  MODE'  1.0 

ENTER  THE  PROPORTION  OF  THE  DEVELOPMENT  COMPUTER  THAT  IS  DEDICATED 
TO  THIS  SYSTEM  DEVELOPMENT  EFFORT  .$ 

ENTER  THE  PROPORTION  OF  THE  AVAILABLE  CAPACITY  OF  THE  DEVELOPMENT  COMPUTER 
THAT  IS  USED  FOP  OTHER  PRODUCTION  WORK  . 0 

ENTER  THE  PROPORTION  CF  THE  SYSTEM  THAT  MILL  EE  CODED  IN  A  HOL-  t.O 

ENTEP  the  NUMBER  CORRESPONDING  TO  THE  PRIMARY  LANGUAGE  TO  BE  USED: 

•  1  •  APL  '4  '  FORTRAN  •  ALGOL  •  l  C»>  ASSEMBLER 

•2'  PL  I  <5'  BASIC  •  3>  JOVIAL  ',11''  PPG 

•S'  COBOL  CMS  PASCAL-ADA  <  12>  OTHER 

ENTER  NUMBER:-  3 

ENTEP  THE  NUMBER  CORRESPONDING  TO  THE  TYPE  OF  YOUR  SYSTEM: 

•1'  REAL  TIME  OP  TIME  CRITICAL  SYSTEM 

■2,-'  OPERATING  S. STEM 

•S')  COMMAND  CONTROL 

■  4 >  BUSINESS  APPLICATION 

■5'  TELECOMMUNICATION  ■  MESSAGE  SWITCHING 
•6>  SCIENTIFIC  S'.  STEM 
PROCESS  CONTROL 

4 
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choose  the  response  below  which  best  describes  yoijr  system. 

'1'  THE  CYC TEN  i:  ENTIRELY  HEW  -  DESIGNED  HMD  CODED  FROM  SCRATCH.  IT  HAS 

many  interface:  and  must  interact  with  other  systems  within  a  total 

MANAGEMENT  INFORMATION  IV ITEM  ITPUCTUPE. 


(g>  THIS  IS  A  NEW  CTAND-ALONE  I VI TEN.  IT  I C  ALIO  DECIGNED  AND  CODED  FROM 
SCRATCH  BUT  IC  I IMFLEP  BECAUSE  THE  INTERFACE  PROBLEM  WITH  OTHER  I YCTEMC 
IS  ELIMINATED. 

•3)  THIC  IS  A  REBUILT  CYCTEM  WHERE  LARGE  SEGMENTS  OF  EXISTING  LOGIC  EXIST. 
THE  PRIMARY  TAIIC  ARE  RECODING*  INTEGRATION.  INTERFACING.  AND  MINOR 
ENHANCEMENTS. 

•4j«HIS  IC  A  COMPOSITE  CYCTEM  MADE  UP  OF  A  SET  OF  INDEPENDENT  SUBSYSTEMS 
WITH  FEU  INTERACTION:  and  INTERFACES  among  THEM.  DEVELOPMENT  OF  THE 
INDEPENDENT  SUBSYSTEMS  WILL  OCCUR  WITH  CONSIDERABLE  OVERLAP. 

*.5>  THIS  IS  A  COMPOSITE  SYSTEM  MADE  UP  OF  A  SET  OF  INDEPENDENT  SUBSYSTEMS 
WITH  A  MINIMUM  OF  INTERACTIONS  AND  INTERFACE:  AMONG  THEM.  DEVELOPMENT 
OF  THE  INDEPENDENT  I UB SYSTEMS  WILL  OCCUR  VIRTUALLY  IN  PARALLEL. 

PAST  DATA  HAVE  SHOWN  THAT  LARGE  SYSTEMS  0200*000  LINES)  APE  TYPICALLY  OF 

TYPE  3.  4.  OR  S- 

ENTER  NUMBER  3 


ENTER  THE  RC'OFOPTION  SF  MEMORY  OF  THE  TARGET  MACHINE  THAT  WILL  EE  UTILISED 
BY  THE  :CFtWhPE  SYSTEM-  .5 

ENTER  THE  PROPORTION  OF  REAL-TIME  CODE!'  .  0 

BELOW  IS  A  SET  OF  MODERN  PROGRAMMING  TECHNIQUES  THAT  MAY  BE  USED  ON 
A  SOFTWARE  DEVELOPMENT  PROJECT.  BESIDE  EACH  APE  5  POSSIBLE 
RESPONSES  INDICATING  THE  DEGREE  OF  USAGE  ON  , OUP  SYSTEM. 


TECHNIQUE 

RE 

SPONSE 

:  TPUCTUPEP  P R'OGRAMM I NG 

a- 

25’: 

.  3>\ 
u. 

-  3- 

DESIGN  CODE  INSPECTION 

-■  i- 

■ 

«—  '  • 

1  £'•» 

i  •'  •« 

■  ***;■ 

top-down  DEVELOPMENT 

•  i » 

*  £.•» 

0-c;_ 

•  3.' 

CHIEF  PROGRAMMER  TEAMS 

C 1  - 

••.25‘. 

1  Cl‘ 

£S-75\ 

•  3  > 

ENTER  1  >  E'<  OF  3  TO  INDICATE  THE  DEGREE  OF  USAGE  EXPECTED  ON  YGL'P  SYSTEM. 
ENTER  ALL  4  RESPONSES  ON  l  LINE.  SEPARATED  BY  A  COMMA,  3. 3* 3- I 

BELOW  APE  4  INDICATOR'S  OF  PERSONNEL  EXPERIENCE  THAT  CAN  IMPACT  THE  COST 
AND  TIME  TO  DC  A  PROJECT.  Bel  IDE  EACH  APE  3  POSSIBLE  ANSWER:  INDICATING  THE 
DEGREE  OF  EXPERIENCE. 


PERSONNEL  EXPERIENCE 


RESPONSE 


-OVERALL  HILL  x  QUALIFICATIONS 

-WITH  DEVELOPMENT  COMPUTER 
-WITH  PROGRAMMING  language • : ■ 
-with  :v:tem  of  similar  :ioe 

AND  APPLICATION 


•  1  ' MINIMAL 
t -  MINIMAL 
■  1 'MINIMAL 

1‘-  MINIMAL 


■  cX  AVERAGE 
•  3. '  h1  V 
'  c  1  HVc=  *■" 

AVERAGE 


■  3  ■  e:  :tens  ive 

■  3 -EXTENSIVE 
•  3 -EXTENSIVE 

■  3- EXTENSIVE 


ENTER  1-  £.  OP  3  TO  INDICATE  THE  DEGREE  OF  EXPERIENCE  OF  YOUR  PERSONNEL. 
ENTER  ALL  4  PEI  PONT  E  S  ON  ONE  LINE,  SEPARATED  BY  A  COMMA  3*2,  3*2 

ENTEP  V OUP  STATE  OF  TECHNOLOGY  FACTOR,  ? 
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YOU  MAY  ENTER  CIOING  INFORMATION  IN  ONE  OF  £  FORM": 

<1>  AN  Q'-'EPALL  PANGE  OF  CIOE-  OR 

(£>  range:  qf  :ize  on  a  mosule-sy-mobule  ea:i:. 

ENTER  1  OP  £  TO  INDICATE  HOU  YOU  NANT  TO  ENTER  IIZING  DATA>  £ 


THE  FOLLOWING  INFORMATION  I'  REOU I  RED  FOP  EACH  OF  THE  MAJOR 

function:  in  the  :yc tens 

FUNCTION  NAME  -  • UP  TQ  £0  CHARACTER: ' 

a  -  the  :malle:t  rdcciple  number  of  :ource  :tatement: 

M  -  THE  MO:t  Lit-  EL  .  NUMBEF  Or  SOURCE  STATEMENT 3 
F  -  THE  LARGE  IT  P0C3IBLE  NUMBER  OF  COURSE  ITATEMENTI 

ALL  INFORMATION  RQP  EACH  FUNCTION  CHGULD  BE  ENTERED  ON  1  LINE. 
SEPARATED  BY  COMMA:. 


ENT£R  THE  NUMBER  OF  MAjOP  FUNCTION:  3 

ENTER  FUNCTION  NAME*  A.  M.  AND  P  FOR  FUNCTION  R  1. 

>  FUNCTION!. 12000* £1500. 23300 

ENTER  FUNCTION  NAME.  A.  M.  AND  P  FOP  FUNCTION  »  £. 

>  FUNCTIONS. 13000-27200- 31400 

ENTER  FUNCTION  NAME-  A.  M.  AND  B  FOP  FUNCTION  R  3. 

>  FUMCT ION3- 1 1300.  13000 <  24200 

ENTER  FUNCTION  NAME.  A.  M«  AND  B  FOR  FUNCTION  R  4. 

>  FUNCTION4-3300- 3500- 14030 

ENTER  FUNCTION  NAME-  A-  M-  AND  E  cOR  FUNCTION  R  3. 
y  FUNCT 1 0N3  -  3  0  0  0  -  1 34  i'i  0  *  1  33 0  0 

ENTER  FUNCTION  NAME-  A.  1-  AND  B  FOR  FUNCTION  R  3. 

FUNCTIONS  -  13500-  i333'0-2£3t-,U 

ENTER  FUNCTION  NAME  *  A.  M-  AND  B  FOP  FUNCTION  R  7. 

1  0 0 0 0 .  i  0 0 •  £•. 7 0 0  0.  .  . 

FUNCTIQN7-  10000-  13£00-i'4700 

**•  illegal  fecponse  -  please  reenter:  functions. i oooo. 13200-24700 

ENTER  FUNCTION  NAME-  A.  M-  AND  B  FOR  FUNCTION  R  3. 

'■  FUNCT  1 0N3 «  1  £5  0  0  -  1  35  0  0  -  £55  0  0 
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It  should  be  noted  that  a  technology  factor,  vice  a 
technology  constant,  is  required  for  SLIM.  By  using  two 
fibinacci  sequences  (0,1, 1, 2, 3, 5, 8...  and  0,2,2,4,6,10...), 
technology  constants  are  internally  assigned  a  technology 
factor.  [Ref.  24:  163]  In  this  example,  the  technology 
factor  of  9  equates  to  a  technology  constant  of  5168. 

SLIM  offers  a  very  powerful  tool  for  firms  lacking 
the  historical  data  necessary  to  calibrate.  A  default  value 
of  0  for  the  technology  factor  signals  SLIM  to  select  a 
technology  factor.  This  is  accomplished  by  taking  the  mean 
technology  factor  of  the  Rome  Air  Development  Center  and 
adjusting  it  in  accordance  with  the  answers  supplied  while 
using  the  Editor  function. 

Now  that  a  file  is  built  for  Thesis  Example,  the 
project  manager  would  want  to  use  the  Estimate  function  to 
make  pertinent  cost,  manpower,  and  time  estimates. 


AVAILABLE  FUNCTIONS  APE: 

CALIBRATE 

EDITOR 

ESTIMATE 

BYE 

function:-  e: t 

INPUT  FILENAME'  THESIS 


INPUT  DATA  CHE'S  V  -  OV 


SUMMARY  OF  INPUT  DATA  PRINTED  •' 

Y  OP  N'T  Y 

:  ijmmm*  v 

rp  IhCljT 

sv  stems  thes  i  :  e:  :am=-u= 

DATE:  IE- 

PROJECT  START:  l '5? 

COST  ELEMENT; 

S,-MV  70  000  • 

STD  DEV  ‘t  MY '■  7000. 

INFLATION  pate 

•  1  0  0 

ENVIRONMENT 

ONLINE  DE'-‘  1 .00 
DEVELOPMENT  TIME  0.30 
LANGUAGE  COBOL 

HOL  USAGE 
PRODUCTION  Tine 

i .  00 

i.i .  i.  ij 

-'STEM 

TYPE  BUSINESS  APPLICATION 
LEVEL  3 

REAL  TIME  CODE 
UTILIZATION 

0.  00 
0 .  t  0 

MODERN  pPQARAMM  •  T*c  PRACTICES 
STRUCTURED  PR'S'? 

TOP-DOWN  DEVELOPMENT  S 

DESIGN.- CODE  IN;p 
CHIEF  PROGRAMMER  TEAMS 

- 

EXPERIENCE 

HVE^hLL  3 

SYSTEM  TYPE 
HARDWARE 

A 

TECHMGLOS’1 

FAC TOP  ? 

n 


simulat  r  art 

TITLE:  THESIS  E:  AMPLE 


E'ATE:  lE-IgE- 


•**  SIMULATION  PUNNING  -  PLEASE  •»n=l I T  **• 


mehn  std  dev 

SYSTEM  SIZE  'STMTS'  143225.  828 5. 

MINIMUM  DEVELOPMENT  TIME  'MONTHS'  31.2  0.9 

DEVELOPMENT  EFFGFT  • MANMONTHS >  2211.4  227. S 

development  cost  •:•:  ttooo- 

OJNINPLATED  DGLLAP ;  •  9214.  1325. 

'.INFLATED  DCLlhPS'  1 042 is.  1514. 


SENSITIVITY  BP'OrlLE  FOP  MINIMUM  TIME  SOLUTION 
(EXPECTED  VALUES  OF  TIME-  EFFGC'T •  AND  COST  FOP  VAPIOUS  SYSTEM  SIZES • 


soupce  stmt: 

MONTHS 

MANMONTHS 

COST  i i Oi.io • 

r-3  Sir. 

124429. 

29.3 

1851. 

7712. 

•:-l  SD' 

1 

30.5 

209-1. 

37  c:  5 . 

MOST  LIKELY 

14S225. 

31.2 

221  1 . 

9214. 

•♦1  SD' 

1494 AO. 

31.7 

2343. 

9785. 

■  +  3  SI" 

1  82  02 1 . 

32.  $ 

2599. 

1 0829. 

A  CONSISTENCY  CHECK  WITH  DATA  FFOM  OThEP  SYSTEMS  OF  THE  SAME  S IZ2  SHOl.'S: 


TOTAL  manmQntk;  •  Z211.- 

O’POJECT  DU=-At!G,(  -  SI. 2  month;. 
AVi;  c-ED='LE  “1.  ■ 

PP'ODUCT  IVITY  •  -.5.  LINES  MM' 


'SPEATEP  than  riOPMAi_  EP-OFT 
WITHIN  -IC4MAL  »AN«£ 

'3PEATEP  "HAN  tG=MAi_  ::  SF  PECDLE 
LESS  THAN  NQPMAL  PPODU'ST IVITY 


v  «ji  4*  ».n  fu 


UNCLASSIFIED 


NAVAL  P0ST8RADUATE  SCHOOL  MONTEREY  CA  F/0  9/2 

A  MACRO  APPROACH  TO  SOFTWARE  RESOURCE  ESTIMATION  AND  LIFE  CYCLE— ETC  <U> 
DEC  81  BR  V0R6AN6 

NL 


DTIC 


Output  is  based  on  PERT  sizing  and  the  software 
equation.  The  standard  deviations  are  extremely  important. 

Mot  only  do  the  standard  deviations  indicate  a  range  about 
the  expected  value,  but  they  also  offer  a  device  for  testing 
system  sensitivity.  All  simulations  are  run  by  generating 
random  variables  within  the  given  standard  deviations  and 
making  use  of  Monte  Carlo  simulation  techniques. 

It  should  be  noted  that  the  consistency  check  indi¬ 
cates  abnormalities  within  the  project  that  will  have  to  be 
considered.  This  consistency  check  is  done  against  the  data 
base  of  the  Rome  Air  Development  Center. 

Given  a  minimum  development  time  of  31.2  months  with 
a  development  effort  of  2211.4  man-months,  the  staffing  of  the 
development  effort,  the  time  of  the  major  milestones,  the 
front-end  estimate,  and  a  risk  analysis  should  be  examined. 

The  front-end  estimates  are  based  on  historical  data 
of  system  size  versus  feasibility  study  time  and  effort,  and 
system  size  versus  functional  design  time  and  effort.  Data 
used  for  this  option  comes  from  IBM-San  Jose.  The  project's 
development  curve  is  determined  and  SLIM,  in  effect,  extra¬ 
polates  backwards  to  derive  the  front-end  time  and  manpower 
requirements.  Using  system  size  to  estimate  the  front-end 
is  certainly  an  unscientific  method,  hence  the  la.rge  uncer¬ 
tainty  bounds.  Yet,  there  is  no  other  feasible  means  of 
estimating  the  front-end  of  a  project  but  through  historical 
data.  Given  the  uncertainty  bounds,  this  method  is  quite 
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satisfactory.  Front-end  estimation  is  an  important  option 
and  is  one  the  project  manager  would  be  wise  to  use;  the 
front-end  can  incur  roughly  fifteen  to  twenty  percent  of 
the  life-cycle  cost. 
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MANLOADING 


TITLE:  ThEIM  E: :hmPLE 


DATE:  12-Sep-81 


THE  TABLE  EELQW  SHQl.iS  THE  MEAN  PPQ JECTEB  EFFOPT 
AND  ASSOCIATED  ■*  OP  ->  STANDARD  DEVIATION  PEC’UIPED 
FOR  DEVELOPMENT.  THE  INPUT  PAPAMEtER'I  APE: 


MEAN 


std  dev 


DEVELOPMENT  EPFOPT  <  MM  '■ 
DEVELOPMENT  TIME  'MONTHS' 


2211.4 

31.2 


227.3 

0.9 


SIMULATION  PUNNING  -  PLEASE  WAIT 


TIME 

PEOPLE- MONTH 

:td  dev 

CUMULATIVE 

manmdnth: 

CUM 

STD  DEV 

' 

i 

i 

JAN  S3 

3. 

0. 

3. 

0. 

! 

FEB  S3 

*?. 

t. 

12. 

1. 

* 

MAP  S3 

14. 

2. 

26. 

3. 

APP  S3 

20. 

s> 

46. 

5. 

MAY  S3 

23. 

3. 

72. 

1? 

JUN  S3 

31. 

4. 

1  03 . 

ii. 

JUL  P3 

37  * 

4. 

140. 

14. 

AUG  S3 

42. 

» 

132. 

19. 

SEP  S3 

47. 

6. 

230. 

24. 

□CT  33 

53. 

6.  •- 

283. 

29. 

NOV  S3 

58. 

7. 

-340. 

35. 

i 

DEC  S3 

63. 

7a 

4  03. 

4d. 

JAN  34 

6? , 

8. 

470. 

48- 

•j 

FEB  34 

71. 

•3. 

541. 

56. 

J 

MAP  34 

75. 

9. 

617- 

64. 

| 

APP  34 

79. 

9. 

696. 

— « .«> 

! 

MAY  34 

S3. 

3. 

779. 

SO. 

JUN  34 

■?7. 

10. 

365. 

89. 

» 

JIJL  34 

3'?. 

10. 

955. 

98. 

-< 

RiJG  34 

33. 

11. 

1047. 

108. 

i 

SEP  34 

?6. 

11. 

1143. 

113. 

r 

OCT  34 

99. 

11. 

1241 . 

123. 

i 

NOV  34 

1 00. 

11. 

1342. 

138. 

DEC  34 

103. 

12. 

1444. 

149. 

• 

JAN  35 

104. 

11. 

1549. 

130. 

FEB  35 

103. 

12. 

1655. 

170. 

MAP  35 

108. 

12. 

176c!. 

131. 

APP  35 

10S. 

12. 

IS70. 

193. 

MAY  35 

1  03 . 

1  £• 

197S. 

204. 

JUN  35- 

-  -lio. 

u. 

-2087. 

215. 

JUL  35 

108. 

12. 

2197. 

223. 

AUG  35 

55. 

6. 

2252. 

MAJOR  MILESTONES 

TITLE:  THESIS  EXAMPLE  DATE:  12- Sep-41 


EXAM  I  NATION  OF  SEVERAL  HUNDRED  SYSTEMS  I  HOW  I  THAT  ESTIMATES  OF  THE 
MAJOR  MILESTONES  OP  A  PROJECT  mF'E  VERY  STABLE  AND  predictable,  the 
MILESTONES  SHOWN  BELOW  ACE  EASED  on  m  TOTAL  DEVELOPMENT  TIME  OF  3l.fi 

month: . 


EVENT 

TINE  FROM  START 
(YEARS ■ 

TIME  FPDM 
■  MONTH 

CRITICAL  DESIGN  REVIEW 

1.12 

13.4 

:v STEMS  INTEGRATION  TEST 

1.74 

20.? 

PROTOTYPE  TEST 

OS 

£4.9 

START  INSTALLATION 

2.42 

£9.  0 

FULL  OPERATIONAL  ChPAEILI 

TV  £.*0 

31.2 

front-end  estimate: 

TITLE:  THE:i:  EXAMPLE  DATE:  12-Sep-;1 


(.LOU) 

TIME (MONTHS' 
(EXPECTED) 

■HIGH  > 

•LOW'- 

EFFORT 'MM) 
■EXPECTED' 

■HIGH'  : 

FEASIBILITY 

STUDY 

7.  1 

7.9 

3.5 

s. 

31. 

55.  : 

FUNCTIONAL 

DESIGN 

?.5 

10.4 

11.3 

1 99  • 

398. 

5?7.  : 

PI  if.  ^'(mL'i'  i  I  I 


TITLE!  THE il  i  E:  AMPLE 


DATE:  12-Iei»-81 


THE  TABLES  BELOW  SHOW  THE  PROBABILITY  THAT  IT  MILL  NOT  TAKE  MOPE  THAN 
THE  INDICATED  AMOUNT  OF  TIME?  EFFORT.  HMD  DOLLARS  TO  DEVELOP  YCUP 
SYSTEM. 


PROBABILITY 

TIME  (MONTHS? 

1. 

39.  1 

5. 

•s 

39.7 

10. 

30.  0 

30. 

v 

30.4 

30. 

30.7 

40. 

31.0 

50. 

31.3 

60. 

31.4 

70. 

•• 

31.7 

80. 

V 

31.9 

80. 

\ 

•  .To  #  3 

95. 

*; 

oo  T* 

ml  1.  •  1 

39. 

33.3 

PROBABILITY  profile 


PROBABILITY 

manmgnth: 

COST  0<  'll  000  • 

’  INFLATED  COST  0 

:  li 000' 

1. 

m. 

1631. 

6130. 

6904. 

5. 

1837. 

7034 . 

7935. 

10. 

1919. 

7515. 

8486. 

30. 

•s 

3030. 

3099. 

9152. 

30. 

\ 

3093. 

3519. 

9633. 

40. 

v 

3154. 

3879. 

1 0043. 

50. 

*t 

3211. 

9314. 

10436. 

60. 

3269. 

9549. 

10309. 

70. 

V 

2331. 

9908. 

11319. 

•30. 

\ 

3403. 

1 0329. 

11700. 

90. 

•; 

2503. 

10912. 

12366. 

95. 

\ 

£586. 

11394. 

13916. 

??. 

\ 

2741. 

12297. 

13948. 

PROBABILITY  ==GFILE 
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Knowing  that  this  project  definitely  cannot  exceed 
42  months,  the  project  manager  can  use  the  Design- to-Risk 
option  to  determine  what  his  maximum  development  time  should 
be  in  order  to  assure  a  99  percent  chance  of  not  exceeding 
42  months.  If  this  time  is  greater  than  the  31.2  minimum 
time,  the  project  manager  has  an  opportunity  to  improve  his 
position  by  decreasing  effort  and  cost.  If  the  resulting 
time  is  less  than  the  minimum  time,  he  can  again  use  this 
option,  but  with  smaller  risk  options,  in  an  effort  to 
decrease  effort  and  cost. 
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DESIGN  tg  ft;: 


TITLE:  THE! 1 1  Ei  iAMF'LE  DATE:  IE-Ief--’. 


DE:i6H-ra-c-i:»  MILL  CPTCh  identify  OPPORTUNITIES  th  :ftwg  money  US IN6  the 
TF:AD£-CFF  lAm  TOGETHER  mI~h  a  SPECIFIED  LEVEL  Qc  =1 ZV  Mr  HOT  EXCEEDING  A 
PEOUIPED  DELIVER'-'  DA”.  PSSULTS  hFE  -SOM»AFED  TD  the  MINIMUM  TIME*  MAXIMUM 
COST  SOLUTION.  THE  MINIMUM  TIME  PARAMETERS  hFE: 

minimum  time  •month;. 

DEVELOPMENT  Err oft  ■ MANMCMTHS '- 
DEVELOPMENT  COST  Hu 00' 


ENTEP  YOUP  MAXIMUM  DEVELOPMENT  TIME  IN  MONTHS. 
42 


SPECIF'.'  THE  Amount  GF  Pi;t-  ASSOCIATED  WITH  the  ABOVE  SCHEDULE 
l.JH I CH  VGU  APE  WILLING  G  ACCEPT: 

..A)  VSPY  HIGH  -  ?'?\  PtQBABILITY  OF  NOT  EXCEEDING  4£.  00  MONTHS 

•  B:*  high  -  s-e-Ot ABILITY  CF  not  EXCEEDING  4c.  00  month" 

US')  MEDIUM  -  ?0\  PROBABILITY  CF  NQT  EXCEEDING  4£.  00  MONTH S 

ENTER  A.  E.  OF  C  A 


ASSUMING  A  c-r;t  OF  NQT  EXCEEDING  4£.  00  MONTHS.  YOUP 
EXPECTED  '50'.  LEVEL.'  PARAMETERS  APE: 

MEAN  STD  DEV 

NEW  DEVELOPMENT  TIME  'MONTHS'  S'?.  31  1.14 

NEW  DEVELOPMENT  EFFDF'T  .MAnmONTHS  1  372.  ?0. 

NEW  DEVELOPMENT  COST  '81000'*  3G33.  S23. 


yqijp  e:  pected  savings  in  :o;t  by  accepting  a  ?•?•.  probability  oc  not 

EXCEEDING  44.00  month;  IS  •»  557?.  *.-:  81000*  COMFAr ED  WITH  The 

MINIMUM  TIME  SOLUTION. 


YOUP  FILE  IS  UPDATED  WITH  ’"HESE  NE'*1  PAPAMETEPS .  C'UN  MANLOADING  AND  CASHFLOW 
OF  LIFE  C '.  C Lt  TO  SEE  HOI*1  THESE  SAVINGS  CAN  B:E  FEALISED. 


31.  2 
3211. 
■?214. 


10  2 


w 


A  CONCICTENCY  CHECK  WITH  DATA  FROM  CTHEP  CYCTEflt  OF  IKE  SAME  CI2E  CHOWC: 


TOTAL  MANMONTh:  •  372. -  WITHIN  NORMAL  RANGE 
PROJECT  PUPATION  '  33. 3  MONTH: "■  WITHIN  NORMAL  RANGE 
AVG  s  PEOPLE'  22'.  '  WITHIN  NORMAL  RANGE 
PRODUCTIVITY  •  164.  LI  NEC '"MM  *  WITHIN  NORMAL  RANGE 


It  should  be  noted  that  given  a  project  duration  of 
39.3  months,  the  consistency  check  now  shows  the  project 
within  the  normal  range  of  the  Rome  Air  Development  Center. 

Now  knowing  that  he  can  plan  on  a  development  time  of 
39.3  months  with  a  99  percent  chance  of  not  exceeding  the  42 
month  limit,  the  project  manager  can  run  the  Linear  Program¬ 
ming  option  to  determine  the  time/effort/cost  data  for  a 
minimum  cost  solution  and  a  minimum  time  solution. 
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LINEUP  PPDi?PPM 


TITLE:  THESIS  EXAMPLE 


DATE:  l£-3«.-Si 


THIS  FUNCTION  USES  THE  TECHNIQUE  OF  LINEAR  PROSPAMMINS  1  SIMPLEX  ALGORUM*" 
TO  DETERMINE  THE  MINIMUM  EFFORT  •  AND  COST'  0*  THE  MIMW  TIME  IN  WHICH 
A  SYSTEM  CAN  BE  BUILT.  t-E  =  ES'L;LTS  ACE  BASED  ON  THE  ACTUAL  MftNPQW£P.  COST. 
AND  SCHEDULE  CONSTANTS  Cc  the  USES'.  COMB  I  HEX*  wjTH  TH£  SYSTEM  CONSTPAINTS 
YOU  HAVE  PROVIDED  EARLIER  TO  YIELD  ft  CONSTRAINED  OPTIMAL  SOLUTION. 


ENTER  THE  MAXIMUM  DEVELOPMENT  COST  IN  DOLLARS  5500000 

ENTER  MAXIMUM  DEVELOPMENT  TIME  IN  MONTHS  -  3'?.  31 

ENTEP  THE  MINIMUM  AND  MAXIMUM  NUMBER  OF  PEOPLE  YOU 
CAN  HAVE  ON  BCnPD  AT  CEAY  MAf. LOADIN'?  TIME-  30**0 


TIME 

EFFORT 

COST  <X  $1000 

MINIMUM 

COST 

39. 3  MONTHS 

■373.  MM 

3636. 

MINIMUM 

TIME 

35.4  MONTHS 

1320.  MM 

5500. 

VOUP  PEAL I  STIC  TRADE-OFF  RESIGN  LIES  BETWEEN  THE  LIMIT*  OF  THE  TABLE  ABOVE. 
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■INTERPOLATION  IN  the  TRADE— OFF  TABLE  BETWEEN  THEtE  LIMITS  mill  PRODUCE  ALL 

acceptable  alternative: .  mould  rau  like  td  :ee  a  trade-off  analysis  mi  thin 
these  limit:  op  n>  ■ 


time 

manmonth: 

cost  ■:  <: 

35.4 

1  320. 

5500. 

36.4 

1181. 

4921. 

37.4 

1  060. 

4416. 

33.4 

954. 

3974. 

39.3 

373. 

3636. 

the  result:  shown  in  thi:  table 'can  be  used  with  design-tg-cqst  op  new 

TIME  TO  GENERATE  an  uPBAtEB  FILE  AND  AN  ENTIRELY  NEW  ARRA'i  OF  CONSEQUENT 
RESULTS  fop  MANLOAD INC*  CASHFLOW.  LIFE  CYCLE.  PICK  ANALYSIS.  COMPUTER  TIME 
AND  FRONT  END  ESTIMATES. 


de;  ign  to 


DATES  t2-:sr-: 


TITLES  THESIS  EXAMPLE 


SLIM  Mfi:  PROVIDED  ITt  BEIT  ESTIMATE  OF  THF  MINIMUM  TIME  AND  CORRESPONDING 
MAXIMUM  EFFORT  AND  CQIT>  TO  DEVELOP  VQl'P  SYSTEM.  THESE  VALUED  APEs 

MINIMUM  TIMES  31.2  MONTH! 

EFFORTS  2211.  MANMONTH I 

COOT  i  1  u 0 0 :■  s  |  3214. 


A  GREATER  EFFORT  1  OP  SOST'.  MOULD  RESULT  IN  A  VERY  RISKY  TIME  SCHEDULE. 
HOWEVER.  IF  A  lOWEF  EFFORT  II  IPECIFIED  •WITHIN  REASONABLE  LIMIT!). 
DEVELOPMENT  II  IT  ILL  FEASIBLE  AS  LONG  AS  YOU  CAN  TAKE  MOPE  TIME. 

ENTER  DESIRED  EFFORT  IN  MANMONTH!  373 


MEAN  STD  DEV 


NEW  DEVELOPMENT  TIME  •MONTH!) 


1.1 


NEW  DEVELOPMENT  COST 


31 000 •  l  3638. 


2  06 . 


YOUR  ftlc  II  UPDATED  with  THE IE  NEW  PARAMETERS .  RUM  MANLOADING  AND  CASHFLOW 
OP  LIFE  CYCLE  To  IEE  nCw  THESE  SAVING:  CAN  BE  REALIZED. 


A  CONSISTENCY  CHECK  with  DATA  FROM  OTHER  SYSTEMS  OF  THE  SAME  SIZE  SHOWS: 


TOTAL  MANMONTH!  •  373.  • 

PROJECT  DURATION  ■  33.3  MONTHS'- 

AVG  ■■  PEOPLE-  22.  ■ 

PRODUCTIVITY  •  164.  LINES  MM • 


WITHIN  NORMAL  RANGE 
WITHIN  normal  RANGE 
WITHIN  NORMAL  range 
WITHIN  NORMAL  RANGE 
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Having  updated  the  file 
project  manager  can  now  use  the 
mine  the  managerial  information 
control  the  project. 


for  Thesis  Example,  the 
Estimate  function  to  deter- 
he  requires  to  plan  and 


MANLOAD  I  NI3 


title !  the;  1 1  e:  .ample 


DATE:  I  c*  I  £►  1 


THE  TABLE  below  show;  "HE  MEAN  projected  effort 
AMD  ASSOC  IhTED  •*  CP  -•  STANDARD  DEVIATION  :  EC'U  I  F'ED 
FOP  DEVELOPMENT ,  THE  INPUT  PARAMETERS  ARE: 

MEAM  STD  DEV 

DEVELOPMENT  EFFORT  .  MU  '  < 7  .  ij 

DEVELOPMENT  TIME  •  MONTHS  ■  •:<?.  3  1.1 


♦  ♦♦  SIMULATION  PUNNIN'3  -  PLEASE  WAIT  ... 
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TIME 


PEOPLE  MONTH 


CUMULATIVE 

manmqnth: 


:~D  DEV 


CUM 

:td  dev 


JAM  33 

1. 

0. 

1. 

0. 

PEB  33 

3 . 

0. 

3  • 

0. 

MAP  33 

4. 

0. 

6 . 

1. 

APP  33 

5. 

1. 

1 1 . 

1. 

MAY  33 

6, 

1 . 

13. 

2. 

JIJM  33 

3. 

1 . 

33. 

2. 

JUL  33 

•4, 

1 . 

35. 

4. 

ftlji, 5  S3 

i  i  . 

1. 

45. 

5. 

:EP  33 

13. 

1. 

57. 

*. 

OCT  33 

13. 

2» 

71 . 

7# 

MOV  33 

15. 

2 . 

35. 

DEC  33 

1  *. 

j 

101. 

1 0. 

JAM  34 

17. 

3  • 

118. 

13. 

FEB  34 

13. 

2. 

136. 

14. 

MAR  34 

13. 

2. 

156. 

1  *  • 

APR  34 

31. 

2. 

176. 

18. 

MAY  34 

ro 

■*. 

j  • 

188. 

30. 

JUN  34 

■N 

331 . 

23. 

JUL  34 

34. 

345 . 

—5. 

AUG  34 

35. 

J  • 

• 

38. 

IEP  34 

33. 

1'  a 

335. 

30. 

OCT  34 

27 . 

Mi 

0*  a 

333. 

2  2. 

NOV  34 

33. 

3. 

343. 

-■*  • 

DEC  34 

33, 

5 
— *  • 

37:3 . 

2*. 

JAM  3*5 

33 . 

4  07. 

43. 

FEB  35 

30. 

3. 

4  2*  ■ 

45. 

MAP  35 

!:  0 . 

J  • 

4*7. 

48. 

APP  35 

31. 

3. 

4*7. 

51. 

MAY  35 

22. 

2 . 

538. 

54. 

JUN  35 

33. 

4. 

561 . 

58. 

JUL  35 

33. 

4. 

583 . 

61. 

AUG  35 

J  a 

4. 

636. 

64. 

:ep  35 

33. 

4. 

*5*. 

33. 

OCT  35 

34. 

4. 

**2. 

71. 

NOV  35 

24, 

4. 

727 . 

75. 

DEC  35 

34. 

4. 

7*0. 

72. 

JAM  3* 

24 . 

4. 

7*5. 

33. 

FEB  33 

24. 

4. 

838. 

2*;. 

MAP  3* 

24. 

4. 

333 . 

3  * 

APP  36 

17. 

-■ 

:■  -t*  0 . 

31. 
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mrjor  mile: tone: 


title:  ThE:i:  ET.RNFLE 


DRTE:  lE-Iep-il 


e'irmi nation  of  :e'-'fp*l  hundred  :v:tem:  ;hom;  that  e:timrte:  of  the 

MH..IOP  MtLECTDME:  OF  R  PROJECT  R*E  VERY  :TRHi_E  RND  PFEBIC  Ti-FLE.  the 

mile: tone:  :hown  belch  rfe  dried  on  r  tdtrl  bevelcfment  time  of  :■ 
month: . 


EVENT 

TIME  FROM  :TRPT 

•yerp: » 

TIME  FROM 
■  MONTH: 

CRITICRL  BE:  IGN  PE'-'IEW 

1.41 

16.9 

:v:tem:  integration  te:t 

3.  19 

££  .  ? 

PROTOTYPE  TE:T 

c.  6£ 

31.4 

:trrt  in : t rllrt i on 

3.  05 

36 . 6 

FULL  OPEPRTICNRL  ORFREILIT 

v  3.:* 

39.3 

crihflcm 


title.-  the:i:  e:-:rmple 


DRTE:  IE-Iep-DI 


THE  TRBLE  BELOW  :hqh:  the  mern  ppojecteb  crshflow 
rnd  r::ocirteb  itrndrpb  bevirtion  peouiped  fop 
development,  the  input  prfrmetep:  RFE: 


MERN  :TI>  DEV 

DEVELOPMENT  EFFOPT  • MM <  373.  90. 

DEVELOPMENT  TIME  ■  MONTH:'1  39.3  l.l 

RVEPRGE  f  MY  ■ t  too  O'  90.  5. 

INFLRT ION  PR TE  0.100  0.015 


I IMULRTI ON  PUNNING  -  PLERIE  WRIT 
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TIME 

t  MONTH  ■ 
MEAN 

:•  !.  i  »*»  o  0  > 

:td  rev 

CUMULATIVE 

MEAN 

C  0  C  T  ■  N  5 1  0  0  0  '• 
CTD  DEV 

jAN  S3 

3. 

0. 

5. 

0. 

FEB  S3 

3. 

1. 

12. 

2. 

MAP  S3 

15. 

w  . 

w_  1  . 

4. 

APR.  S3 

£*c. 

3. 

43. 

<  ■ 

MAY  S3 

4. 

77. 

11. 

JUN  S3 

34. 

c, 

111. 

16. 

JUL  S3 

41. 

7 

151. 

22 . 

RU  G  33 

47. 

7  u 

133. 

29 . 

CEP  S3 

54. 

6  • 

252. 

•  ■‘7 

OCT  S3 

6  0. 

3. 

312. 

45. 

NOV  S3 

67. 

1  0. 

579. 

55. 

DEC  S3 

7  . 

11. 

452. 

66. 

JAN  S4 

30. 

12. 

532. 

I?™* 

FEB  S4 

$5. 

14. 

613. 

30. 

MAP  S4 

31. 

14. 

709. 

1  03. 

APP  S4 

33. 

16. 

306. 

117. 

MAY  34 

103. 

16. 

31  0. 

1 32 . 

JUN  34 

110. 

17. 

1020. 

143. 

JUL  34 

116. 

17. 

1135. 

165. 

AUG  34 

121. 

13. 

1257. 

133. 

CEP  34 

126. 

20. 

1  334. 

2  01 . 

OCT  34 

133. 

20. 

1516. 

220. 

NOV  34 

133. 

52. 

1654. 

24  0. 

DEC  34 

144. 

»3. 

1737. 

261. 

JAN  35 

143. 

?  •>. 

1345. 

232. 

FEB  35 

154. 

c  • 

2033. 

305. 

MAP  35 

153. 

24. 

2257. 

323 . 

APP  35 

161. 

c3. 

2413. 

351. 

MAY  35 

166. 

27. 

2534. 

375. 

JUN  35 

169. 

-,ci 

2753. 

4  00. 

JUL  35 

174. 

2926  • 

425. 

HUG  35 

173. 

29. 

3 1  04 . 

451. 

CEP  35 

132. 

29. 

5236. 

477. 

OCT  35 

135. 

23. 

3471. 

5  04 . 

NOV  35 

137. 

30. 

3653. 

5  31. 

DEC  35 

130. 

23. 

5343. 

553. 

JAN  36 

132. 

31. 

4  04  1  . 

537. 

FEE  36 

136. 

50. 

4236. 

615. 

MAP  36 

136. 

30. 

44  53. 

644. 

APP  36 

99. 

16. 

4531 . 

644  • 

THE  TABLE  ABOVE  CHQi.i:  the  A'-'EPAGE  f,  MCNTH  AND  CUMULATIVE  CQCT  IN  INFLATED 
DOLL  AFC .  TO  PPPCOPH  "Hi:.  ANAL'"  Cl  C  IN  CUPPENT  DOLLAP  C  >  CHANGE  '.'CUP  VALUE  FOP 
INFLATION  =ATE  TO  0  I'M  "HE  DATA  FILE  FOP  THIO  CvCTEM. 


i 
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risk  analysis 


TITLE:  THESIS  EXAMPLE  DATE:  12-Iep-3l 


THE  TABLES  EELD'.i  :hOM  the  PROBABILITY  THAT  it  MILL  not  TAPE  MOPE  than 
THE  INDICATED  AhOlnT  qf  TIME,  EFFORT •  AND  DOLLARS  TO  DEVELOP  VOUF' 
SYSTEM. 


PROBABILITY 

TIME  • MONTHS' 

1. 

38.7 

5. 

37.4 

10. 

^■*7  o 

20. 

V 

33.4 

30. 

38.7 

40. 

39.  0 

50. 

39.3 

*0. 

V 

39.8 

70. 

■f 

39.9 

80. 

4  0.  3 

90. 

•; 

40.  3 

95. 

\ 

41.2 

99. 

rj 

42.  0 

PROBABILITY  PROFILE 


PPOBAB IL I  TV 

manmonth: 

COST  o;  Bl 000' 

INFLATED  cost 

l.  % 

884. 

3157. 

2318. 

5.  *- 

— o«; 

i  j  • 

3298. 

3238. 

10. 

758  • 

“  ~j  “T  'Z' 

3481 . 

20.  ■. 

797. 

3484. 

3733. 

30.  Y 

828. 

3529. 

3929. 

40.  \ 

850. 

3C  oc 

j*  J  ■ 

.  4098. 

50.  ■-. 

873. 

3833. 

4252. 

80.  *. 

398. 

3890. 

4408. 

70.  \  - 

920. 

3748. 

4578. 

80.  *. 

849. 

3811. 

4772. 

90.  \ 

988. 

3908. 

5043. 

9*. .  *t 

1021. 

3977 . 

5283. 

99.  •. 

1  038 . 

4  i  18. 

5839. 

PROBABILITY  PPG" I LE 
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DOCUMENTATION 


TITLES  THE  1 1 1  E:  AMPLE 


DATE :  12-Se»-31 


IT  IS  POSSIBLE  TO  ESTIMATE  THE  NUMBER  DF  PAGES  OF  DOCUMENT  ATI DM  *  BASED 
ON  DATA  COLLECTED  FPOM  I EVER AL  HUNDRED  SYSTEMS. 

THE  EXPECTED  NUMBER  FOP  YOUR  SYSTEM  IS  10035  PAGES. 

THE  ?0‘.  RANGE  IS  FPOM  28G4  TO  £4343  PAGES. 


DO  YOU  WANT  THE  PROJECTIONS  DISPLAYED  MONTHLY 'Ml.  QUARTERLY <Q> 
OP  YEARLY  ■' Y>  ?  0 


LIFE  CYCLE 


SYSTEM!  THESIS  EXAMPLE 


DATE!  12-Sep-B  1 


THE  TABLE  BELOW  SHOWS  THE  MEAN  PROJECTED  EFFORT 
AND  CASHFLOW  'AND  ASSOCIATED  STANDARD  DEVIATIONS.' 
OVER  THE  LIFE  CYCLE  OF  THE  SYSTEM.  *LL 
PROJECTIONS  APE  BASED  ON  AN  OPTIMAL  AF PLICATION  OF 
RESOURCES  OVER  time.  THE  INPUT  PARAMETERS  APE: 


MEAN  STD  DEV 


DEVELOPMENT  time  'MONTHS:'  3?.  3 
-LIFE  CYCLE  EFFORT' MM..  £218.7 

AVG  COST -MV  SI  000'  50. 

INFLATION  =ATE  0.100 


1 .  t 

CJ 

0.  015 


SIMULATION  PUNNING  -  PLEASE  WAIT  •* 
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OTR  ENDING 

PEOPLE 
MERN  CTD 

DEV 

CQCT  OTP 
MERN 

•  :  .  f.  i  o  o  o » 

CTD  DEV 

CUM  COCT 
MERN 

; ;  ?.  1  0  0  0  1 

CTD  DEV 

MRP  3.3 

■J 

w  ■ 

0. 

88. 

4. 

83. 

4. 

JlJN  83 

6 . 

1 . 

34. 

18. 

118. 

18. 

CEP  33 

ii. 

1 . 

148. 

84. 

854. 

?7 

DEC  33 

15. 

2 

800. 

38.  . 

454. 

66. 

MRP  34 

13. 

2 . 

855. 

41 . 

710. 

103. 

JUN  34 

t—iC.  • 

2 

3 1 0 . 

48. 

1019. 

143. 

CEP  34 

3  • 

366  a 

55. 

1333. 

£01. 

DEC  34 

£7  • 

3  • 

418. 

84. 

1798. 

381 . 

MRR  85 

CO. 

3. 

484. 

72  a 

8880. 

383. 

JUN  35 

4 . 

509. 

~*"T 

8788. 

4  08. 

CEP  35 

33  • 

4. 

535. 

86. 

3305. 

480. 

DEC  35 

34. 

4. 

581 . 

39. 

3366. 

58 1 . 

MAR  86 

C4 . 

4. 

538. 

39. 

4443. 

646. 

JUN  38 

?4 . 

4. 

595. 

9 '3. 

5044. 

732  • 

CEP  38 

C4 . 

4. 

808. 

94. 

5849. 

820. 

DEC  38 

33. 

8  08 . 

94. 

62*6. 

9  08 . 

MRR  37 

-■l_  . 

3  • 

804. 

94. 

'  6858 . 

996  a 

JUN  37 

31. 

3. 

?‘?6a  • 

97. 

7453. 

1  038 . 

CEP  37 

£9. 

3  a 

537. 

93. 

8037. 

1 1 87 . 

DEC  37 

83. 

3. 

583. 

95. 

38  04 . 

124,:* . 

riRR  33 

£6. 

543. 

34. 

9148. 

!.  383. 

JUN  33 

84. 

518. 

34. 

'?  6  6  2  a 

1 4  0  3 . 

CEP  33 

22 . 

£  • 

486. 

84. 

10147. 

1473. 

DEC  33 

80. 

2 . 

449. 

72. 

10599. 

1539. 

MAR  39 

13. 

2. 

487. 

773. 

1 1 08 1 . 

1800. 

JUN  39 

16 . 

Z‘ 

393. 

72. 

11415. 

1857. 

CEP  39 

15. 

r* 

1—  a 

359. 

85. 

11775. 

1710. 

DEC  39 

13. 

2 . 

389. 

62.  • 

1 8 1  08 . 

1757. 

MRP  90 

11. 

i . 

294. 

6  1  a 

18393. 

1 3  0  Ci . 

JUN  90 

10. 

i . 

884. 

58. 

18883. 

1929. 

CEP  90 

9. 

i . 

838. 

49. 

18397. 

1373. 

DEC  90 

3. 

i . 

813. 

48. 

131 08 . 

1903. 

MRP  91 

6. 

i . 

130. 

41  . 

1 3290. 

1930. 

JUN  91 

5. 

i . 

1  62  a 

::9. 

1 3449. 

1953. 

CEP  91 

5. 

i . 

135. 

jC  a 

13587. 

1973. 

DEC  91 

4. 

i . 

180. 

31. 

1  37  08 . 

1990. 

MRP  98 

3 . 

i . 

101. 

Z' 

1  38  03 . 

8  0  05 . 

JUN  98 

3. 

i . 

36  a 

23. 

13*'?5. 

2  0 1 7 . 

CEP  98 

8. 

i . 

74. 

80. 

1 3989. 

8083. 

DEC  98 

£  • 

0. 

88. 

19. 

14031 . 

1 0  :'7 . 

LIFE  CYCLE  PROJECT IONC 


SLIM  is  not  intended  for  one-time  use.  It  can  serve 


the  project  manager  throughout  the  life  of  the  project.  As 
estimates  become  more  refined  or  as  requirements  change,  the 
file  can  be  updated  and  SLIM  estimates  can  serve  to  aid  in 
the  updating  of  plans  and  in  the  control  of  the  project. 

3.  CONTRACTING  APPLICATION 

SLIM  can  be  extremely  useful  in  evaluating  vendor  pro¬ 
posals  for  software  contracts.  3v  requesting  the  development 
effort,  development  time,  and  system  size  of  past  projects, 
as  well  as  the  estimated  new  project  size  in  PERT  format, 
in  the  Request  for  Proposal  (RFP),  each  vendor  can  be  cali¬ 
brated  and  the  proposals  evaluated  for  validity. 

If  the  user  also  determines  system  size,  even  when  using 
a  default  technology  factor  of  0  (zero),  a  best  time/effort/ 
cost  estimation  can  be  made  from  which  the  vendors  can  be 
again  be  evaluated. 

As  the  number  of  clients  of  the  SLIM  estimating  package 
grows  (Table  7),  the  ability  to  even  further  validate  vendor 
proposals  also  grows.  Knowing  that  a  vendor  used  SLIM  to 
determine  his  time/effort/cost  estimates,  the  project  manager 
can  now  verify  the  proposal  using  the  vendor's  SLIM  inputs  to 
determine  the  proposal's  validity. 

SLIM  can  do  much  toward  eliminating  cost  and  schedule 
overruns.  Not  only  can  it  assist  in  project  development  and 


able  7 


SLIM  Clients  as  of  20  June  1981 

1.  American  Management  Systems,  Arlington,  Virginia 

2.  Blue  Cross/ Blue  Shield  of  Illinois,  Chicago,  Illinois 

3.  Boeing  Computer  Services,  Inc.,  Seattle,  Washington 

4.  Burroughs  Corporation,  World  Headquarters,  Detroit, 
Michigan 

5.  Burroughs  Corporation,  Program  Products  Division, 
Radnor,  Pennsylvania 

6.  Burroughs  Corporation,  Program  Products  Division, 
Atlanta,  Georgia 

7.  Burroughs  Corporation,  Program  Products  Division, 

Miami ,  Florida 

3.  Burroughs  Corporation,  Program  Products  Division, 
Irvine,  California 

9.  Burroughs  Corporation,  Program  Products  Division, 
Charlotte,  North  Carolina 

10.  Central  Intelligence  Agency,  Washington,  D.C. 

11.  Computer  Management,  Inc.,  Atlanta,  Georgia 

12.  Dynamics  Research  Corporation,  Wilmington,  MA 

13.  Federal  Aviation  Administration,  Washington,  D.C. 

14.  Honeywell  Federal  Systems  Operations,  McLean,  Virginia 

15.  Honeywell  Large  Information  Systems  Division,  Phoenix, 
Arizona 

16.  Honeywell  Process  Management  Division,  Phoenix,  Arizona 

17.  IBM  Federal  Systems  Division,  Manassas,  Virginia 

18.  IBM  Federal  Systems  Division,  Westlake  Village, 
California 

19.  IBM  Federal  Systems  Division,  Gaithersburg,  Maryland 
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Table  7  continuted- 

20.  PACTEL,  Ltd.,  London,  United  Kingdom 

21.  Planning  Research  Corporation,  McLean,  Virginia 

22.  United  States  Department  of  Defense  (includes  Army, 
Navy,  Air  Force,  Marine  Corps,  and  all  Defense  Agencie 

23.  Vougnt  Corporation,  Dallas,  Texas 

Source:  Quantative  Software  Management,  Inc. 


control,  but  also  by  allowing  the  user  to  easily  determine 
which  vendors  are  submitting  valid  proposals. 

C.  CRITERIA  FOR  THE  GOODNESS  OF  A  SOFTWARE  COST  MODEL 

Some  method  of  evaluating  SLIM  is  necessary  to  determine 
its  effectiveness  as  a  software  costing  model.  Barry  W.  Boehm 
and  Ray  W.  Wolverton,  of  TRW  Defense  and  Space  Systems  Group, 
have  proposed  nine  measures  of  goodness  as  a  basis  on  which 
to  compare  a  software  cost  model.  [Ref.  4:  129] 

1 .  Definition 

The  model  must  clearly  define  which  costs  it  is  estimating 
and  which  costs  it  is  not. 

2 .  Fidelity 

The  estimates  that  are  generated  by  the  model  must  be 
close  to  actual  expended  costs. 

3 .  Objectivity 

The  model  must  not  allow  for  subjective  factors  that  can 
sway  the  model  in  any  desired  direction. 

4 .  Constructiveness 

The  user  must  be  able  to  understand  why  the  model  gives 
the  estimate  it  does.  Also,  the  model  must  help  the  user 
understand  the  software  job. 

5 .  Detail 

The  model  must  be  able  to  easily  subdivide  a  project 
into  phases  and  activities. 
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6 .  Stability 


The  model  must  reflect  appropriately  sized  output  per 
unit  of  input.  No  mathematical  surprises  can  be  generated 
by  the  model. 

7 .  Scope 

The  model  must  cover  the  class  of  software  project  to 
be  estimated. 

3 .  Ease  of  Use 

The  model’s  inputs,  outputs,  and  options  must  be  easy 
to  understand  and  specify. 

9 .  Pro spec five ness 

The  model  must  not  depend  on  information  that  is  not 
well  known  until  the  end  of  the  project.  It  must  be  able  to 
function  in  a  useful  manner  with  the  information  at  hand. 

D.  EVALUATING  SLIM  AGAINST  THE  CRITERIA 

3oehm  and  Wolverton  suggest  that  this  criteria  is  impor¬ 
tant  in  determining  the  utility  of  a  software  estimating 
model.  Using  this  criteria,  the  utility  of  SLIM  can  be 
assessed . 

1 .  Definition 

SLIM  clearly  defines  what  it  is  estimating:  size,  time, 
effort,  cost,  risk,  trade-offs,  manpower,  cashflow,  code 
production,  documentation,  development  computer  time,  and 
the  front-end  of  the  project. 
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2 .  Fidelity 

SLIM  has  been  validated  against  over  four  hundred  pro¬ 
jects  from  the  Rome  Air  Development  Center  and  others. 

3 .  Objectivity 

It  is  extremely  difficult  to  sway  SLIM  because  of  the 
data  constraints  inherent  to  the  problem  as  well  as  those 
management  constraints  serving  co  define  the  software  pro¬ 
ject's  environment.  Resultant  times  less  than  the  minimum 
possible  time  are  not  allowed. 

4 .  Constructiveness 

SLIM  is  completely  consistent  with  the  underlying  theory. 
In  addition,  it  offers  the  user  an  insight  into  why  con¬ 
straints  are  either  reasonable  or  unreasonable.  The  most 
important  aspect  in  understanding  the  software  development 
effort  is  the  identification  of  minimum  time;  SLIM  immediately 
identifies  minimum  time. 

5 .  Detail 

The  front-end  of  the  project  is  estimated  in  terms  of 
time,  effort,  and  manpower.  System  development  is  estimated 
in  terms  of  time,  effort,  manpower,  code  production  rate, 
risk,  and  budget.  The  Operations  and  Maintenance  phase  is 
estimated  in  terms  of  manpower,  budget,  cost  and,  risk. 
Activities  are  not  estimated.  Activities  are  based  on  spe¬ 
cific  organization  methodology  and  is  within  the  domain  of 
the  project  manager,  not  SLIM. 
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All  output  is  consistent  with  the  exponential  and  quantum 
characteristics  of  the  model. 

7 .  Scope 

SLIM  is  applicable  for  all  classes  of  software  systems 
involving  a  group  problem  solving  effort.  SLIM  is  based  on 
the  human  intercommunication  within  the  software  process. 

8 .  Ease  of  Use 

SLIM  inputs  and  outputs  are  extremely  easy  to  understand. 
As  system  design  becomes  more  refined,  input  ranges  become 
smaller  and  outputs  become  more  accurate.  Output  is  in 
terms  of  usable  management  parameters. 

9 .  Prospectiveness 

SLIM  is  completely  consistent  with  the  amount  and 
availability  of  information.  Based  on  input  characteristics, 
SLIM's  output  informs  the  user  of  the  degree  of  accuracy. 

E.  SLIM  WEAKNESSES 

Although  it  has  been  shown  to  be  a  very  valuable  manage¬ 
ment  tool,  SLIM  does  display  several  weaknesses. 

There  is  a  tremendous  range  of  values  for  the  difficulty 
gradient,  |7D|,  between  the  rebuild  and  composite  II  systems. 
Although  increased  uncertainty  compensates  fui  this  range, 
further  classification  of  systems  within  this  range  of 
difficulty  would  further  enhance  program  accuracy. 


SLIM  can  be  inconsistent  with  current  Department  of 
Defense  life-cycle  methodology.  SLIM  output  assumes  project 
continuity.  The  sequence  of  events  leading  to  project 
approval  prior  to  each  life-cycle  milestone  can  lead  to 
breaks  in  the  project  schedule.  This  inconsistency,  if 
anticipated  by  the  project  manager,  must  be  taken  into  con¬ 
sideration  when  planning  the  software  project. 

F.  SUMMARY 

SLIM  offers  the  project  manager  an  extremely  powerful 
tool  for  managing  the  software  development  process  in  terms 
of  planning,  budgeting  and  control.  Sizing  through  the  PERT 
sizing  technique,  simulation  via  the  Monte  Carlo  technique, 
linear  programming,  and  sensitivity  analysis  through  risk 
profiles  provide  an  accurate  time/effort/cost  analysis. 

SLIM's  accuracy  has  been  validated  for  over  four  hundred 
systems  spanning  the  entire  range  of  system  types:  from 
operating  systems,  real-time,  and  scientific  applications  to 
the  most  mundane  business  application.  SLIM  can  be  used 
throughout  the  entire  planning  and  development  phases  of  the 
project  in  order  to  facilitate  planning  and  control.  Project 
data  is  easily  updated  so  that  SLIM  can  be  an  effective  tool 
when  requirements  or  constraints  change. 

Applying  SLIM  to  Barry  W.  Boehm  and  Ray  W.  Wolverton’s 
criteria  for  the  goodness  of  a  software  cost  model  shows 
SLIM  to  be  an  extremely  viable  software  estimation  model. 
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SLIM  does  display  a  few  minor  weaknesses.  More  system 
types  need  to  be  identified  in  the  difficulty  range  between 
rebuild  and  composite  II  systems.  SLIM  output  can  be  incon¬ 
sistent  with  current  Department  of  Defense  life-cycle 
methodology.  These  weaknesses  are  minor  and  certainly  do 
not  distract  from  the  effectiveness  of  SLIM  as  a  powerful 
tool  for  the  software  project  manager  (Table  3). 

An  extremely  important  facet  of  SLIM  is  that  it  takes 
into  account  the  transition  zone,  as  discussed  in  Chapter 
III.  It  is  an  effective  tool  for  small,  medium  and  large 
projects.  If  any  two  of  the  following  four  attributes  apply 
to  the  project,  SLIM  can  be  used: 

Ss  is  greater  than  or  equal  to  5000 
Peak  manpower  is  greater  than  or  equal  to  3  people 
Development  time  is  greater  than  or  equal  to  6  months 
Cost  is  greater  than  or  equal  to  $100,000. 
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Table  8 


Putnam's  Version  of  the  Characteristics 
of  a  Good  Software  Cost  Estimating  System 


1.  Should  have  a  sound  phenomenological  basis  that  relates 
to  other  similar,  known  processes  and  which  contributes 
to  understanding  the  software  system  development  process. 

2.  Should  apply  to  all  organizations  and  classes  of  software. 

3 .  Can  be  adapted  to  any  organizational  structure  and  way 
of  doing  business. 

4.  Is  consistent  with  existing,  known  data  over  the  entire 
size  range. 

5.  Can  be  easily  calibrated  or  "tuned"  to  a  specific 
organization . 

6.  Accepts  management  constraints  on  time,  cost,  manpower. 

7 .  Should  have  "what  if"  capability  to  specify  alternative 
cost,  schedule,  manpower  and  risk  conditions  within 
constraint  bounds. 

3.  Produces  bounded  solution  sets. 

9.  Produces  accuracy  bounds  on  all  answers. 

10.  Permits  risk  evaluation  and  risk  specification. 

11.  Should  produce  consistent  manpower  and  budget  implemen¬ 
tation  plans  for  each  time-cost-effort  solution. 

12.  Should  be  capable  of  adapting  to  anticipated  changes  in 
environment,  technology,  language,  skill,  complexity  and 
modern  programming  practices  . 

13.  Input  information  is  easy  to  estimate. 

14.  Gives  a  measurable  achievement  projection  (rate  of  code 
production) . 

15.  Produces  a  projection  of  life  cycle  time,  effort,  man¬ 
power  and  budget  together  with  accuracy  bounds  on  these 
quantities  . 
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Table  3  continued- 


16.  Is  capable  of  adaption  to  future  (new)  environments. 
Makes  extrapolation  into  such  new  environments  straight 
forward  and  relatively  safe. 

17.  Allows  partitioning  into  major  system  phases. 

13.  Permits  separate  analysis  of  modules.  Aggregation  of 
these  pieces  should  show  when  and  how  much  "overhead 
work"  (management,  integration,  test  S  validation, 
documentation)  has  to  be  done. 


reproduced  this  with  permission  of  L.H.  Putnam, 
Quantitative  Software  Management,  Inc. 


VI.  CONCLUSIONS 


Planning  and  controlling  the  software  development  process 
has  shown,  in  the  past,  to  be  an  extremely  difficult  task. 

The  estimation  of  resource  requirements,  development  costs, 
risk  profiles  and  project  feasibility  has  often  proven  to  be 
inaccurate,  thus  costing  the  user  both  time  and  dollars.  How- 
every,  by  using  obtainable  management  parameters,  and  simple 
engineering  and  operations  research  techniques,  estimating 
can  be  done  easily  and  accurately  by  taking  a  macro  approach 
to  the  estimation  problem. 

The  methodology  discussed  in  the  study,  as  developed  by 
Lawrence  H.  Putnam,  is  based  on  the  empirical  findings  of 
the  relationship  between  the  software  life-cycle  and  the 
Rayleigh  curve,  mathematically  expressed  as 

2 

y'  =  2Kate-at 


The  Rayleigh  equation  can  be  used  to  determine  project  man¬ 
loading,  cumulative  manpower,  and  cash  flows. 

A  powerful  software  economics  tool,  the  software  equation 


Ss 


Ck  K 


1/3 


4/3 


offers  the  opportunity  to  trade-off  manpower,  development 
time,  and  the  development  environment  in  order  to  obtain  an 
optimal  development  solution  in  terms  of  minimum  cost  or 
minimum  time. 


The  automated  software  estimation  package,  SLIM,  makes 
use  of  these  two  equations,  as  well  as  engineering  and 
operations  research  techniques,  to  form  an  extremely  power¬ 
ful  tool  for  the  project  manager. 

SLIM  and  its  underlying  mathematical  basis  reflect  intui¬ 
tive  observations  of  the  software  development  process: 

Each  software  system  has  its  own  minimum  development  time 

Large  projects  take  more  effort 

Complex  projects  require  more  effort  and  time 

Improving  software  development  tools  and  techniques 
results  in  an  improved  development  environment  which, 
in  turn,  effects  development  in  a  positive  manner 

A  gradual  growth  in  manpower  is  the  most  efficient 
manloading  pattern 

SLIM  is  based  on  the  historical  data  of  past  development 
projects  which  allows  it  to  be  calibrated  to  the  development 
history  of  the  user.  In  addition,  it  can  function  as  a  'what 
if  analysis  tool  so  that  the  user  can  design  the  software 
development  project  based  on  cost,  schedule,  or  risk.  SLIM, 
being  completely  consistent  with  the  criteria  set  forth  by 
Barry  W.  3oehm  and  Ray  W.  Wolverton,  offers  the  project 
manager  of  any  software  project  a  viable  software  estimation 
model . 

SLIM  does,  however,  reflect  several  weaknesses:  the 
necessity  of  identifying  further  system  types  in  the  diffi¬ 
culty  range  between  the  rebuild  and  composite  II  systems, 
and  the  possible  inconsistency  with  current  Department  of 
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Defense  life-cycle  methodology.  As  previously  stated,  these 
weaknesses  do  not  distract  from  the  effectiveness  of  SLIM 
as  a  powerful  tool  for  the  software  project  manager. 

3y  using  SLIM,  the  project  manager  is  able  to  accurately 
answer  the  four  management  questions  in  terms  of  costs  and 
resources : 

Is  the  project  feasible? 

What  are  the  resource  requirements? 

How  long  will  it  take? 

What  are  the  risks? 

3eing  able  to  answer  these  questions,  the  project  manager 
can  now  prevent  the  mistakes  of  past  projects  and  accurately 
plan  and  control  the  software  project. 


APPENDIX  A 


Variables  That  Correlate  Significantly 
With  Programming  Productivity 
[Ref.  28:  64,  65] 

Question  or  Variable  Response  Group  Productivity 

Mean  Productivity  Change 

(DSL/MM)  (DSL/MM) 


Customer  interface 
complexity 

<Normal 

500 

Normal 

295 

>Normal 

124 

376 

User  participation 
in  the  definition  of 
requirements 

None 

491 

Some 

267 

Much 

205 

286 

Customer  originated  Few 

program  design  changes  297 

Many 

196' 

101 

Customer  experience 
with  the  application 
area  of  the  project 

None 

318 

Some 

340 

Much 

206 

112 

Overall  personnel 
experience  and 
qualif icat ions 

Low 

132 

Average 

257 

High 

410 

278 

Percentage  of  pro-  <25% 

grammers  doing  devel-  153 
opment  who  participated 
in  design  of  functional 
specif ications 

25-50% 

242 

>50% 

391 

238 

Previous  experience 
with  operational 
computer 

Minimal 

146 

Average 

270 

Extensive 

312 

166 

Previous  experience 
with  programming 

Minimal 

122 

Average 

225 

Extensive 

385 

263 

Previous  experience 
with  application  of 
similar  or  greater 
size  and  complexity 

Minimal 

146 

Average 

221 

Extensive 

410 

264 

Ratio  of  average 
staff  size  to  dura- 

<0.5 

305 

0.5-0. 9 
310 

>0  .  9 

173 

132 

t ion (people /month) 
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V 


Hardware  under  concur¬ 
rent  development 

-  No 

297 

Yes 

177 

120 

Development  computer 
access,  open  under 

0% 

226 

1-25% 

274 

>2  5% 

357 

131 

Development  computer 
access,  closed 

0-10% 

303 

11-85% 

251 

>8  5% 

170 

133 

Classified  Security 
environment  for 
computer  and  25%  of 
programs  and  data 

No 

289 

Yes 

156 

133 

Structured 

programming 

0-3  3% 

169 

34-66% 

>66% 

301 

132 

Design  and  code 
inspections 

0-33% 

220 

34-66% 

300 

>66% 

339 

119 

Top  down  development 

0-33% 

196 

34-66% 

237 

>66% 

321 

125 

Chief  programmer  team 
usage 

0-33% 

219 

34-66% 

>66% 

408 

189 

Overall  complexity 
of  code  developed 

<Average 

314 

>Average 

185 

129 

Complexity  of  appli¬ 
cation  processing 

<Average 

349 

Average 

345 

>Average 

168 

181 

Complexity  of 
program 

<Average 

289 

Average 

299 

>Average 

209 

80 

Overall  constraints 
on  program  design 

Minimal 

293 

Average 

286 

Severe 

166 

107 

Program  design  con¬ 
straints  on  main 
storage 

Minimal 

391 

Average 

277 

Severe 

193 

198 

Program  design  con¬ 
straints  on  timing 

Minimal 

303 

Average 

317 

Severe 

171 

132 

Code  for  real-time 
or  interactive  opera- 

<10% 

279 

10-40% 

337 

>40% 

203 

76 

tion,  or  executing 
under  severe  timing 
constraint 
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Percentage  of  code 

0-90% 

91-99% 

100% 

for  delivery 

159 

327 

265 

106 

Code  classified  as 

0-33% 

33-66% 

>66% 

non-mathematical  ap- 

188 

311 

267 

79 

plication  and  I/O  for¬ 
matting  programs 


Number  of  classes  of  0-15 

16-80 

>80 

items  in  the  data  base  334 
per  1000  lines  of  code 

243 

193 

141 

Number  of  pages  of  0-32 

33-38 

>83 

delivered  documenta-  320 
tion  per  1000  lines  of 

252 

195 

125 

delivered  code 


APPENDIX  B 


Department  of  Defense  Memorandum 
Concerning  SLIM 

The  following  memorandum  serves  to  focus  Department  of 
Defense  interest  in  SLIM,  notify  automated  data  processing 
users  of  its  implications  as  a  tentative  standard  Department 
of  Defense  methodology,  and  to  notify  users  of  the  contracted 
training  sessions  conducted  by  Quantative  Software  Management, 
Inc  • 
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OFFICE  OF  THE  ASSISTANT  SECRETARY  OF  DEFENSE 


.VASHINGTON  DC  :C30I 

8  MAY  1331 


MEMORANDUM  FOR  ADP  POLICY  COMMITTEE  (PROGRAM  MANAGEMENT) 

SUBJECT:  Contract  Support  for  Standard  Software 
Development  Estimates 


we  have  been  working  together  for  some  time  to  improve  the 
Department's  capability  for  estimating  software  development 
resource  requirements.  In  1976  a  DoD  working  group  selected 
a  two  part  methodology.  This  approach  has  been  under  test 
at  a  large  number  of  DoD  software  development  centers  since 
1978. 

Recently,  the  first  part  of  the  tentative  standard 
DoD  methodology  entered  the  commercial  market  as  an 
automated  model  accessible  through  commercial  timesharing. 

I  have  become  sufficiently  impressed  with  the  ease  of  use  and 
the  ready  response  to  "what  if"  analysis,  in  the  commerical 
version,  to  obtain  funding  for  a  DoD-wide  license  for  this 
product.  It  is  my  hope  that  this  will  expedite  widespread 
use  of  this  capability. 

Under  the  contract  which  we  have  negotiated,  OSD  has  paid  the 
annual  license  fee  for  DoD-wide  use  and  for  four  one  week 
training  sessions  which  we  plan  to  hold  at  DODCI.  Any 
organization  in  DoD  which  wishes  to  use  the  capability  will 
write  a  delivery  order  against  our  contract  and  will  pay  for 
usage;  training  for  a  limited  number  of  persons  will  be  free 
(except  for  TDY  costs  if  necessary).  Additional  details  are 
attached. 

It  has  been  demonstrated  to  ray  satisfaction  that  we  can  save 
large  amounts  of  money  if: 

-  We  do  not  try  to  do  the  impossible,  i.e.,  develop 
software  in  less  than  the  minimum  time  required. 

-  We  make  informed  decisions  about  reducing  gold 
plating,  i.e.,  focus  software  development  on  the  minimum 
essential  requirements. 

-  We  optimize  the  application  of  manpower,  i.e.,  a 
3mall  stretch-out  in  schedule  planned  at  the  outset  may 
substantially  reduce  overall  cost. 

-  We  monitor  valid  thresholds  for  deviation  from  plan, 
i.e.,  know  what  reasonable  deviations  from  plan  are. 
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At  least  one  person  at  any  activity  which  plans  to  use  SLIM 
should  be  trained  in  the  use  of  the  model  prior  to  making  any 
extensive  use.  The  first  training  session  has  been  filled. 

We  are  taking  nominations  for  future  sessions.  If  you  wish 
to  nominate  people  to  receive  training,  please  provide  my 
office  with  the  name,  organization  and  telephone  number  of 
those  persons  wishing  to  attend  the  10-14  August  session  by 
30  June.  Similar  information  should  be  provided  by  14  August 
for  the  two  remaining  sessions  which  have  been  scheduled  for 
the  October -November  1981  and  February-March  1982  timeframes. 
Specific  dates  on  these  sessions  will  be  provided  later. 

Your  assistance  in  giving  this  information  the  broadest 
possible  distribution  would  be  appreciated.  My  points  of 
contact  for  this  effort  are  Mr.  Robert  Cooper,  695-2554, 

(AV  225-2554)  and  Ms.  Scarlett  Curry,  697-8632  (AV  227-8632). 
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GENERAL  CONTRACT  INFORMATION 


The  contract  has  been  issued  by: 

Defense  Supply  Service  -  Washington 
Room  1D245,  The  Pentagon 
Washington,  D.C.  20310 
Attn:  Mrs.  Katie  E.  Moulder 

AUTOVON  227-6021 
Commercial  202  697-6021 

The  Contract  Number  is:  MDA903-81-D-0062 

The  contract  is  for  the  acquisition  of  an  annual  lease  and 
license  fee  for  unrestricted  use  of  a  proprietary  software 
package.  Software  Life  Cycle  Management  Model  (SLIM)  for  all 
DoD  organizations;  and  for  access  to  the  model  thru  tele¬ 
processing  services,  also  provided  for  under  the  contract. 
The  software  license  fee  has  been  paid  by  the  Office  of  the 
Secretary  of  Defense.  SLIM  is  resident  on  the  American 
Management  Services,  Inc.,  computer  systems.  Teleprocessing 
services  to  access  SLIM  will  be  ordered  via  call  orders  to 
the  contract. 

Complete  copies  of  the  contract  and  additional  information 
may  be  obtained  from  the  Contracting  Officer's  Technical 
Representative : 

Rob  Cooper 

Assistant  Director  Data  Automation 
OASD(C)  MS  DDA  Fm  1A658  Pentagon 
Washington,  D.C.  20301 

ACQUISITION  APPROVAL 

The  Office  of  the  Secretary  of  Defense  has  approved  the 
acquisition  of  this  capability  for  software  development 
organizations,  organizations  that  monitor  contract  software 
development,  and  audit  or  cost  estimating  organizations. 

A  delegation  of  procurement  authority  has  been  obtained 
which  covers  all  DoD  activities  of  the  type  described  above. 
A  "2068"  has  been  processed  thru  GSA  to  obtain  Sharing 
Program  approval.  Any  further  action  of  this  type  will  be 
taken  by  the  COTR  if  it  appears  necessary  as  a  result  of 
unexpected  growth  in  DoD  wide  usage  of  the  contract. 

By  virtue  of  the  actions  described  above,  potential  users 
within  DoD  have  the  authority  to  issue  call  orders  through 
their  own  acquisition  activity  for  use  of  SLIM,  subject  to 
local  fund  availability. 
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Call  orders  which  exceed  $13,000  should  be  coordinated 
telep’nonically  with  the  COTR  prior  to  issuance  to  facilitate 
planning . 

ORDERING  INFORMATION 

Orders  may  be  issued  under  this  contract  from  1  May  1981 
thru  30  April  1982.  Information  concerning  renewal  of  the 
contract  will  be  furnished  at  a  later  date . 

Orders  should  be  issued  thru  properly  executed  DD  Form  1155 
and  mailed  to: 

American  Management  Systems,  Inc. 

1777  Kent  Street 
Arlington,  VA  22209 

Two  copies  of  each  call  order  will  be  sent  to  the  COTR.  An 
Installation  Representative  (IR)  will  be  designated  by  each 
ordering  activity.  The  ordering  activity  should  provide 
Defense  Supply  Service  Washington  with  the  name,  mailing 
address,  and  telephone  number  of  the  IR.  The  name  and 
address  of  the  IR  will  also  be  cited  in  the  call  order*  so 
that  invoices  may  be  forwarded  to  the  IR  for  certification 
of  receipt  of  services.  The  call  order  shall  site  the 
cognizant  paying  office.  IR's  will  certify  and  approve 
invoices  for  payment  and  forward  them  to  the  paying  office. 

*31ock  14  DD  Form  1155 

PRICING  INFORMATION  SUMMARY 

(These  are  GSA/TSP  prices.  Reference  should  be  made  to  the 
contract  for  more  detailed  information) 

Remote  Terminal  Connect  Charges 


Washington,  DC  Metro  Area 
1290  baud 

Outside  Washington,  DC 
up  to  1200  baud 

Communications  Charges 
TELENET 

CPU  Utilization  Charges*  $.14/RU**  $.08/RU 

DECSYSTEM-20 

*  A  50%  surcharge  will  be  added  to  the  CPU  costs. 

**  RU  =  Resource  Unit 


$7. 00/hr  $4 .00/hr 

Plus  communications  charge 

$7. 00/hr  $7. 00/hr 


Prime  Hours  Non-Prime 

$7. 00/hr  $4. 00/hr 
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File  Storage  Charges  1-1000  pages  $  .64/page/mo 

(Permanent)  1001-2000  pages  $  .39/page/mo 

2001-4000  pages  $  .26/page/mo 

Over  4000  pages  $  .18/page/mo 

ESTIMATING  CALL  ORDER  COSTS 

A  rudimentary  method  for  estimating  the  cost  of  using  SLIM 
is  to  estimate  the  number  of  manhours  available  to  operaxe 
the  model,  e.g.,  2  people  X  half  a  day  X  two  days  per  week 
equates  to  16  hours  per  week,  assuming  the  people  don't  work 
together  on  one  terminal.  Costs  per  hour  can  be  expected  to 
range  between  $15  and  $75  per  hour.  The  variance  between 
these  amounts  relate  to  the  sophistication  of  the  users  and 
the  amount  of  detailed  printing  of  schedules,  etc.  Costs  at 
the  high  end  may  indicate  that  a  greater  benefit  is  being 
obtained . 

TRAINING  INFORMATION 
Instructor:  Mr.  Lawrence  Putnam 

Training  Vendor*: 

Quantitative  Software  Management  (QSM) 

1057  Waverly  Way 
McLean,  Virginia  22107 
(703)  790-0050 

*The  training  vendor  will  certify  attendance  and  course 
completion  for  administration  purposes  not  for  billing  - 
training  organizations  are  not  billed,  as  the  courses  have 
been  prepaid  by  OSD 

Location  of  Training  oite: 

DoD  Computer  Institute 
Building  175 
Washington  Navy  Yard 
Washington,  D.C.  20374 

Length  of  Course:  Five  (5)  days 

Course  Cost:  Tuition  -  paid  by  OSD,  no  cost  to  trainees' 

organisation 

TDY  -  paid  by  trainees'  organization  as 
required 
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The  following  documentation  shall  be  furnished  to  each 
trainee : 

SLIM  Users  Guide 
AMShare  Users  Guide 

Tutorial  Test,  "Software  Cost  Estimating  and  Life  Cycle 
Control:  Getting  the  Software  Numbers,"  IEEE  Cat  No 

EHO  165-1 

3ooklet,  "SLIM"  -  Sample  Output 

Folder,  QSM,  Schematic  Diagram  of  Software  Life  Cycle 
Methodology 

Student  workbook  containing  exercises  and  examples  in 
use  of  SLIM  and  AMShare 
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